I’m also thinking about if that might be the reason for the lock. In any way, is it an option to make messageThreadId an atomic and just get rid of the mutex lock in isThisTheMessageThread?
This could be solved in a way, that isThisTheMessageThread is only reporting true after windows did what ever additional platform specific code did run. However, I don’t know the exact implications of that change concerning user code, but maybe this is not possible to be an issue anyhow?
The thread, that is calling setCurrentThreadAsMessageThread can’t at the same time also call isThisTheMessageThread. You can change the message thread ID to an undef value while doing the windows specific stuff, so that the previous message thread does not assume it is the message thread, while the windows specific bits are running.
So the only semantics that would change, are that doPlatformSpecificShutdown and doPlatformSpecificInitialisation would be executed while (for this thread) isThisTheMessageThread returns false instead of true as of right now. If that poses an issue, as in non-internal code is executed that could be adopted, you could still reimplement isThisTheMessageThread to handle this edge-case with another atomic value.
There is still the edge case of the “previous” message thread being reported true as the message thread and then is doing work assuming it is still the message thread, while another thread is pulling the rug using setCurrentThreadAsMessageThread. But I fail to see how the current implementation is guarding against that race-condition. So there might be another set of guard-rails installed, that render the above scenario mood anyway.