Bug ID 22108
Summary Figure out a better strategy for thread safety between the debugger thread
OS Windows NT
Component All Bugs
Right now the strategy is to stick a lock in every method of ProcessWindows where there might be contention. This leads to difficult to analyze situations, and it's not clear if the current mutex locations are either necessary or sufficient to protect against race conditions. Bug 21883, for example, was caused by a race condition where the main thread acquired a lock, signalled the debugger thread to do something and then wait for it to complete. But the "do something" acquired the same lock, so it never completed. There may be a better strategy, such as posting events to a message queue, etc that make these issues go away.