Block the attaching/detaching threads if GC is in progress (#3956)

Currently, the threads that are detaching from or attaching to the runtime
can end up spinning for a long time in the ThreadStore lock for the entire
duration of a GC because the lock is held while GC is in progress. This
problem becomes quite visible when Windows thread pool injects a couple
hundreds of worker threads into a process.

This change fixes the problem by adding an option to the lock to block
spinning threads on the GC event if GC is in progress.

With this change, I see a couple percent improvement on micro-benchmarks.

1 files changed, 1 insertions, 8 deletions

diff --git a/src/Native/Runtime/threadstore.cpp b/src/Native/Runtime/threadstore.cpp
index e8f650c2f..4074094c2 100644
--- a/src/Native/Runtime/threadstore.cpp
+++ b/src/Native/Runtime/threadstore.cpp
@@ -61,7 +61,7 @@ PTR_Thread ThreadStore::Iterator::GetNext()
 
 ThreadStore::ThreadStore() : 
     m_ThreadList(),
-    m_Lock()
+    m_Lock(true /* writers (i.e. attaching/detaching threads) should wait on GC event */)
 {
     SaveCurrentThreadOffsetForDAC();
 }
@@ -129,13 +129,6 @@ void ThreadStore::AttachCurrentThread(bool fAcquireThreadStoreLock)
     pAttachingThread->Construct();
     ASSERT(pAttachingThread->m_ThreadStateFlags == Thread::TSF_Unknown);
 
-    // The runtime holds the thread store lock for the duration of thread suspension for GC, so let's check to 
-    // see if that's going on and, if so, use a proper wait instead of the RWL's spinning.  NOTE: when we are 
-    // called with fAcquireThreadStoreLock==false, we are being called in a situation where the GC is trying to 
-    // init a GC thread, so we must honor the flag to mean "do not block on GC" or else we will deadlock.
-    if (fAcquireThreadStoreLock && (RhpTrapThreads != 0))
-        RedhawkGCInterface::WaitForGCCompletion();
-
     ThreadStore* pTS = GetThreadStore();
     ReaderWriterLock::WriteHolder write(&pTS->m_Lock, fAcquireThreadStoreLock);