diff options
author | Sergiy Kuryata <sergeyk@microsoft.com> | 2017-06-22 02:17:03 +0300 |
---|---|---|
committer | GitHub <noreply@github.com> | 2017-06-22 02:17:03 +0300 |
commit | b2f2c1ee217361240c08c7c26403f6f33cc99841 (patch) | |
tree | d2337160705598b4caf4585b67a7847a225cbb3a /src/Native/Runtime/threadstore.cpp | |
parent | 98015d079804c686c5b0ae70c639ca22ab5dccfc (diff) |
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.
Diffstat (limited to 'src/Native/Runtime/threadstore.cpp')
-rw-r--r-- | src/Native/Runtime/threadstore.cpp | 9 |
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); |