[Support] ThreadPoolExecutor fixes for Windows/MinGW

[andrewng]

Summary

Changed ThreadPoolExecutor to no longer use detached threads and instead
to join threads on destruction. This is to prevent intermittent crashing
on Windows when doing a normal full exit, e.g. via exit().

Changed ThreadPoolExecutor to be a ManagedStatic so that it can be
stopped on llvm_shutdown(). Without this, it would only be stopped in
the destructor when doing a full exit. This is required to avoid
intermittent crashing on Windows due to a race condition between the
ThreadPoolExecutor starting up threads and the process doing a fast
exit, e.g. via _exit().

The Windows crashes appear to only occur with the MSVC static runtimes
and are more frequent with the debug static runtime.

These changes also prevent intermittent deadlocks on exit with the MinGW
runtime.

[andrewng]

This patch basically reduces the amount of dependence that ThreadPoolExecutor has on what is effectively undefined behaviour. The changes have been based on issues that have been observed when running LLD on Windows built with the MSVC (2015 & 2017) static run-times and MinGW LLD on Windows.

The patch has been tested on Ubuntu 18.04.3 LTS. I have checked that there is little to no impact on LLD lit testing performance, as the lit testing disables the "fast" exit mode of LLD. In fact, this patch appears to give a slight performance improvement with higher core counts.

[mstorsjo]

FWIW, this seems to touch on areas also (partially, incompletely) discussed earlier in D53968. (In that one, the issues seemed to be specific to builds with LLVM_LINK_LLVM_DYLIB enabled.)

Also regarding deadlocks on exit in MinGW, for cases with libstdc++ with winpthreads, there are some known such deadlocks that were caused by signaling a condvar without holding the corresponding mutex (see https://sourceforge.net/p/mingw-w64/bugs/774/ for a report on the matter); if I recall correctly this particular deadlock should now be fixed with the latest version of winpthreads, but there might still be other deadlocks lingering.

[rnk]

How come we have both lib/Support/Parallel.cpp and lib/Support/ThreadPool.cpp? What is the difference? I thought this was the general LLVM threadpool and I was going to send this over to @mehdi_amini who added that in rG396abbb6f045232f92439dbce052db3177a474f9, but I guess @zturner added Parallel.cpp.

[mehdi_amini]

In D70447#1760618, @rnk wrote:

How come we have both lib/Support/Parallel.cpp and lib/Support/ThreadPool.cpp? What is the difference? I thought this was the general LLVM threadpool and I was going to send this over to @mehdi_amini who added that in rG396abbb6f045232f92439dbce052db3177a474f9, but I guess @zturner added Parallel.cpp.

LLD started the Parallel.h thread-pool in 2013, unfortunately they didn't do it in libSupport so it grew inside LLD. I added ThreadPool.cpp in 2015 to LLVM, I wasn't aware about the LLD implementation (that's what happens when utilities aren't put in libSupport...). Zachary noticed that later, and moved the LLD implementation in libSupport in 2017. However I haven't seen a plan for reconciliation the two.

I'm not fond of global state in general (this patch is also a good example of why), and so reluctant to the Parallel.cpp implementation.

[ruiu]

Aren't Parallel and ThreadPool different? We are using parallel_for_loop but we are not using any thread pool.

[mehdi_amini]

In D70447#1762490, @ruiu wrote:

Aren't Parallel and ThreadPool different? We are using parallel_for_loop but we are not using any thread pool.

It seems to me that parallel_for_loop is nothing else than a thin abstraction over a thread pool?

https://github.com/llvm/llvm-project/blob/master/llvm/lib/Support/Parallel.cpp#L35

[andrewng]

I have also tested this patch with LLD built with libc++ on Ubuntu 18.04.3 LTS.

Does anyone have any comments on the actual patch itself?

I think it's beyond the scope of this patch to resolve the issues regarding the existence of both Parallel.cpp and ThreadPool.cpp. I agree with @ruiu that they serve different purposes and although some functionality could be shared/merged, I'm not entirely sure it would be worthwhile. Until we get to C++17, we're kind of stuck with Parallel.cpp for now...

[rnk]

I raised the question of merging the thread pool implementations if possible because this code is subtle and hard to understand, and I was hoping I could get out of understanding it by reusing some code that already works. Now that I look at the other thread pool, I see it doesn't manage a global thread pool instance, so it doesn't suffer from the shutdown bugs you are running into. I will chalk that up as a win for not using global variables. =P

Given that this code is already written to use a global default executor instance, I think your proposal as I understand it makes sense:

• Create the threadpool lazily on first access with static locals.
• Stop the threads on llvm_shutdown if and when that is called, but do not deallocate any memory.
• Deallocate the memory if and when the image is unloaded via a static unique_ptr.

I see that LLD today calls llvm_shutdown to destroy ManagedStatics:
https://github.com/llvm/llvm-project/blob/master/lld/Common/ErrorHandler.cpp#L59
Please update that comment to indicate that this will also stop any threads that have been spawned, and this is critical for avoiding crashes on shutdown. It's actually a waste of time to deallocate other ManagedStatics, so someone might try to remove this at some point.

However, I wonder if LLD (and any other hypothetical clients of Parallel.h) should explicitly cancel, join, or detach threads during shutdown instead.

[andrewng]

• Stop the threads on llvm_shutdown if and when that is called, but do not deallocate any memory.

To be clear (and as stated in the code comment), this only stops the threads from taking on more tasks and does not actually wait for running threads to finish. The important thing that does occur, is that it ensures there is no further thread creation going on which could cause a crash on Windows as the main thread is doing process exit.

• Deallocate the memory if and when the image is unloaded via a static unique_ptr.

This also joins the threads, again to avoid intermittent crashes on Windows.

I see that LLD today calls llvm_shutdown to destroy ManagedStatics:
https://github.com/llvm/llvm-project/blob/master/lld/Common/ErrorHandler.cpp#L59
Please update that comment to indicate that this will also stop any threads that have been spawned, and this is critical for avoiding crashes on shutdown. It's actually a waste of time to deallocate other ManagedStatics, so someone might try to remove this at some point.

I will update the comment. This is already needed for -time-passes for LTO and I'm not sure it's entirely safe to generalize that all ManagedStatics do not need to be "shutdown".

However, I wonder if LLD (and any other hypothetical clients of Parallel.h) should explicitly cancel, join, or detach threads during shutdown instead.

The only truly "safe" option is to always join threads on exit. This should avoid any possible undefined behaviour. However, this has been ruled out for performance reasons :(.

[andrewng]

Updated the comment about llvm_shutdown() in LLD.

[andrewng]

Ping.

[ruiu]

llvm/lib/Support/Parallel.cpp

137

OK, I had to take a look at ManagedStatic's class definition to understnad that ManagedStatic is a pointer-ish class which defines operator*.

ManagedStatic::operator* calls RegisterManagedStatic if it is not registered yet. So I guess you don't actually have to create a unique pointer, but instead you can just do return &*ManagedExec;.

[andrewng]

llvm/lib/Support/Parallel.cpp

137

As mentioned in the comment, the unique_ptr is used to actually destroy the ThreadPoolExecutor via the destructor which "stops" the ThreadPoolExecutor and also waits for the threads to complete.

The "destroy" of the ManagedStatic only "stops" the ThreadPoolExecutor and does not wait for the threads to complete.

[rnk]

Sorry, I lost track of this.

llvm/lib/Support/Parallel.cpp

137

You don't truly need unique_ptr to set up an atexit call, all you need is an atexit callback that runs after the ManagedStatic is destroyed. I think the idiomatic way to do that is to make your own class with a ctor/dtor pair that saves a pointer to the ThreadPoolExecutor, and then calls the appropriate methods on it when it is destroyed. I think that will make it clearer that no memory deallocation is occuring.

[andrewng]

llvm/lib/Support/Parallel.cpp

137

With the unique_ptr, the ThreadPoolExecutor is destructed and its memory is deallocated. That was the intention and hence the use of unique_ptr.

Are you saying you would prefer that there is no memory deallocation of the ThreadPoolExecutor?

[rnk]

+@MaskRay

llvm/lib/Support/Parallel.cpp

137

I see, no, I think I just misunderstood.

I guess there is a use case here that we aren't handling, which is multiple LLVM sessions in one process, where LLVM is shutdown multiple times. The way this code is structured, the thread pool will be created, started, "stopped", and then it will remain stopped for all future sessions. Right now LLD is the only client, but this code is in Support, so it should be general. I see that it is not used by the rest of LLVM. Perhaps it should be moved back to LLD Core, so that we can make such assumptions about process lifetime.

[MaskRay]

Right now LLD is the only client, but this code is in Support, so it should be general. I see that it is not used by the rest of LLVM. Perhaps it should be moved back to LLD Core, so that we can make such assumptions about process lifetime.

lld/Common/Threads.h is the only user of llvm/Support/Parallel.h. parallelForEach and parallelSort in lld do not take a context parameter, and hence the implementation of llvm/Support/Parallel.h uses a function-local static variable. If we can add a context parameter (llvm::ThreadPool), we may be able to make llvm/Support/Parallel.h more general and probably re-implement it on top of lib/Support/ThreadPool.cpp . If we can achieve that goal, do we still need to move the parallel utilities to lld?

[rriddle]

FWIW I've been using parallel::for_each in a few places in MLIR to do multi-threading, because it seemed like the right solution for what I needed. From what I gather here it seems like I should switch all of those usages to ThreadPool instead. If we can't resolve the deficiencies present in the current implementation it would be nice to move it out of Support/ so that others don't make the same mistake.

[andrewng]

In D70447#1787132, @MaskRay wrote:

lld/Common/Threads.h is the only user of llvm/Support/Parallel.h. parallelForEach and parallelSort in lld do not take a context parameter, and hence the implementation of llvm/Support/Parallel.h uses a function-local static variable. If we can add a context parameter (llvm::ThreadPool), we may be able to make llvm/Support/Parallel.h more general and probably re-implement it on top of lib/Support/ThreadPool.cpp . If we can achieve that goal, do we still need to move the parallel utilities to lld?

I think the lack of a context parameter was deliberate to closer mimic the C++17 execution policies feature.

[andrewng]

llvm/lib/Support/Parallel.cpp

137

Another solution would be to add support for "restarting" to this patch. It probably wouldn't be super efficient but it should be possible to handle "multiple shutdowns". Although it has to be said that "multiple shutdowns" just doesn't really sound right...

[andrewng]

llvm/lib/Support/Parallel.cpp

137

There is potentially another alternative to using ManagedStatic / llvm_shutdown() by instead using std::at_quick_exit() along with std::quick_exit(). As far as I can tell, std::quick_exit() is equivalent to _exit(), except for the calling of the std::at_quick_exit() handlers.

Could this be a preferred option?

[rnk]

I guess I like the quick_exit idea. Supporting multiple shutdowns of a thread pool seems fraught with complexity.

I also think it's kind of reasonable to keep the Parallel.h APIs simple. You don't actually want to have more than one threadpool per process running at the same time, so if we were to change all the APIs to pass a context parameter, I'm not sure that'd be a good thing.

[MaskRay]

In D70447#1790286, @rnk wrote:

I also think it's kind of reasonable to keep the Parallel.h APIs simple.

+1

llvm/lib/Support/Parallel.cpp

137

Can you elaborate how you'd use quick_exit and at_quick_exit?

[andrewng]

llvm/lib/Support/Parallel.cpp

137

Instead of ManagedStatic, I would create a similar "holding" class that would hook into std::quick_exit() using std::at_quick_exit() to perform the "stop". However, this means that LLD would need to call std::quick_exit() rather than _exit().

In my current prototyping of this alternative, I'm actually running into a new issue with the MSVC static run-time, in that I appear now to be intermittently losing output to stderr and thus getting random lit test failures for where LLD is expected to fail and output an error message. Note that in these situations, LLD is exiting in a thread from the ThreadPoolExecutor!

[mehdi_amini]

In D70447#1790286, @rnk wrote:

I guess I like the quick_exit idea. Supporting multiple shutdowns of a thread pool seems fraught with complexity.

Why exactly? Isn't it just about joining threads and deleting them? I feel I am missing something.

I also think it's kind of reasonable to keep the Parallel.h APIs simple. You don't actually want to have more than one threadpool per process running at the same time, so if we were to change all the APIs to pass a context parameter, I'm not sure that'd be a good thing.

I'm not sure I totally agree with this: a global thread pool without preemption and priority inversion seems to be easily leading to deadlock through starvation. It is also breaking composability of library components since you may end-up enqueuing to the same pool from a thread in the pool.
Explicitly controlling the context may be suboptimal in some cases, but at least it allows to keep things scoped inside a component.

[andrewng]

In D70447#1792191, @mehdi_amini wrote:

I'm not sure I totally agree with this: a global thread pool without preemption and priority inversion seems to be easily leading to deadlock through starvation. It is also breaking composability of library components since you may end-up enqueuing to the same pool from a thread in the pool.

There is already a "primitive" guard to prevent nesting of parallel invocations. Although this guard could also prevent other threads (not belonging to the "parallel" thread pool) from enqueuing parallel tasks.

llvm/lib/Support/Parallel.cpp

137

Another problem with std::quick_exit() / std::at_quick_exit() is that MinGW does not support it!

[rnk]

Given that quick_exit won't work then, let's do this thing. I don't think multiple llvm_shutdown is a real use case for anyone using these APIs today.

[MaskRay]

llvm/lib/Support/Parallel.cpp

47

std::lock_guard

51

Why if (Stop) break

74

Why detach?

79

You can use

static ManagedStatic<ThreadPoolExecutor, object_creator<ThreadPoolExecutor>,
                     ThreadPoolExecutor::Deleter>
    ManagedExec;

[andrewng]

llvm/lib/Support/Parallel.cpp

47

I will also change stop() and add() to use a scoped lock which is actually my preferred style.

51

This is an "early out" in the case that the pool is stopped before all the threads of the pool have been created.

74

This is to follow the general guideline that a thread should either be detached or joined at exit.

[andrewng]

Updated to address review comments.

[stella.stamenova]

@thakis @int3 I spent some more time trying to diagnose the recent issues with lld and macho and I am starting to think that the problem is the race condition that this change was meant to fix. I am not sure why this is no longer "fixed", but the callstack and intermittent failure on Windows in debug seem to match the issue:

2021-09-02T10:02:23.0425691Z # command stderr:
2021-09-02T10:02:23.0426059Z PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
2021-09-02T10:02:23.0426250Z 
2021-09-02T10:02:23.0426749Z  #0 0x00007ff7b76e2b50 std::_Iterator_base12::_Orphan_me_unlocked(void) C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\xmemory:1202:0
2021-09-02T10:02:23.0427127Z 
2021-09-02T10:02:23.0427617Z  #1 0x00007ff7b76e2afa std::_Iterator_base12::_Orphan_me_locked(void) C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\xmemory:1215:0
2021-09-02T10:02:23.0427973Z 
2021-09-02T10:02:23.0428466Z  #2 0x00007ff7b76e2c7f std::_Iterator_base12::_Orphan_me_v2(void) C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\xmemory:1163:0
2021-09-02T10:02:23.0428826Z 
2021-09-02T10:02:23.0429346Z  #3 0x00007ff7b76e0484 std::_Iterator_base12::~_Iterator_base12(void) C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\xmemory:1132:0
2021-09-02T10:02:23.0429687Z 
2021-09-02T10:02:23.0430356Z  #4 0x00007ff7b7fd6884 std::_Vector_const_iterator<class std::_Vector_val<struct std::_Simple_types<class lld::macho::LinkEditSection *>>>::~_Vector_const_iterator<class std::_Vector_val<struct std::_Simple_types<class lld::macho::LinkEditSection *>>>(void) (d:\a\_work\1\b\llvm\debug\bin\ld64.lld.exe+0xb96884)
2021-09-02T10:02:23.0430896Z 
2021-09-02T10:02:23.0431547Z  #5 0x00007ff7b7fd68e4 std::_Vector_iterator<class std::_Vector_val<struct std::_Simple_types<class lld::macho::LinkEditSection *>>>::~_Vector_iterator<class std::_Vector_val<struct std::_Simple_types<class lld::macho::LinkEditSection *>>>(void) (d:\a\_work\1\b\llvm\debug\bin\ld64.lld.exe+0xb968e4)
2021-09-02T10:02:23.0432069Z 
2021-09-02T10:02:23.0432514Z  #6 0x00007ff7b7fbc19b <lambda_c567cf7a7ebd717fdb2c0648998ac190>::~<lambda_c567cf7a7ebd717fdb2c0648998ac190> (d:\a\_work\1\b\llvm\debug\bin\ld64.lld.exe+0xb7c19b)
2021-09-02T10:02:23.0432837Z 
2021-09-02T10:02:23.0433372Z  #7 0x00007ff7b7fc0c5b std::_Func_impl_no_alloc<<lambda_c567cf7a7ebd717fdb2c0648998ac190>,void>::~_Func_impl_no_alloc<<lambda_c567cf7a7ebd717fdb2c0648998ac190>,void> (d:\a\_work\1\b\llvm\debug\bin\ld64.lld.exe+0xb80c5b)
2021-09-02T10:02:23.0433797Z 
2021-09-02T10:02:23.0434285Z  #8 0x00007ff7b7fc0c88 std::_Func_impl_no_alloc<<lambda_c567cf7a7ebd717fdb2c0648998ac190>,void>::`scalar deleting destructor' (d:\a\_work\1\b\llvm\debug\bin\ld64.lld.exe+0xb80c88)
2021-09-02T10:02:23.0434602Z 
2021-09-02T10:02:23.0435172Z  #9 0x00007ff7b7fc0c1a std::_Func_impl_no_alloc<<lambda_c567cf7a7ebd717fdb2c0648998ac190>,void>::_Delete_this C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\functional:937:0
2021-09-02T10:02:23.0435580Z 
2021-09-02T10:02:23.0436062Z #10 0x00007ff7b76e33dc std::_Func_class<void>::_Tidy(void) C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\functional:1047:0
2021-09-02T10:02:23.0436411Z 
2021-09-02T10:02:23.0436906Z #11 0x00007ff7b76dff84 std::_Func_class<void>::~_Func_class<void>(void) C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\functional:973:0
2021-09-02T10:02:23.0437251Z 
2021-09-02T10:02:23.0437656Z #12 0x00007ff7b76e01b4 std::function<(void)>::~function<(void)>(void) (d:\a\_work\1\b\llvm\debug\bin\ld64.lld.exe+0x2a01b4)
2021-09-02T10:02:23.0437895Z 
2021-09-02T10:02:23.0438626Z #13 0x00007ff7bc4bfc57 <lambda_723fb941fa194635c9894a04ff313f20>::~<lambda_723fb941fa194635c9894a04ff313f20> (d:\a\_work\1\b\llvm\debug\bin\ld64.lld.exe+0x507fc57)
2021-09-02T10:02:23.0438947Z 
2021-09-02T10:02:23.0439491Z #14 0x00007ff7bc4bfeeb std::_Func_impl_no_alloc<<lambda_723fb941fa194635c9894a04ff313f20>,void>::~_Func_impl_no_alloc<<lambda_723fb941fa194635c9894a04ff313f20>,void> (d:\a\_work\1\b\llvm\debug\bin\ld64.lld.exe+0x507feeb)
2021-09-02T10:02:23.0439895Z 
2021-09-02T10:02:23.0440372Z #15 0x00007ff7bc4bff18 std::_Func_impl_no_alloc<<lambda_723fb941fa194635c9894a04ff313f20>,void>::`scalar deleting destructor' (d:\a\_work\1\b\llvm\debug\bin\ld64.lld.exe+0x507ff18)
2021-09-02T10:02:23.0440692Z 
2021-09-02T10:02:23.0441276Z #16 0x00007ff7bc4bfeaa std::_Func_impl_no_alloc<<lambda_723fb941fa194635c9894a04ff313f20>,void>::_Delete_this C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\functional:937:0
2021-09-02T10:02:23.0441677Z 
2021-09-02T10:02:23.0442156Z #17 0x00007ff7b76e33dc std::_Func_class<void>::_Tidy(void) C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\functional:1047:0
2021-09-02T10:02:23.0442511Z 
2021-09-02T10:02:23.0443008Z #18 0x00007ff7b76dff84 std::_Func_class<void>::~_Func_class<void>(void) C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\functional:973:0
2021-09-02T10:02:23.0443354Z 
2021-09-02T10:02:23.0443755Z #19 0x00007ff7b76e01b4 std::function<(void)>::~function<(void)>(void) (d:\a\_work\1\b\llvm\debug\bin\ld64.lld.exe+0x2a01b4)
2021-09-02T10:02:23.0443993Z 
2021-09-02T10:02:23.0444469Z #20 0x00007ff7bc4bf6c5 llvm::parallel::detail::`anonymous namespace'::ThreadPoolExecutor::work D:\a\_work\1\s\llvm-project\llvm\lib\Support\Parallel.cpp:109:0
2021-09-02T10:02:23.0444779Z 
2021-09-02T10:02:23.0445211Z #21 0x00007ff7bc4bf8c9 <lambda_c9242529638530c2607074b83d50e781>::operator() D:\a\_work\1\s\llvm-project\llvm\lib\Support\Parallel.cpp:52:0
2021-09-02T10:02:23.0445508Z 
2021-09-02T10:02:23.0446030Z #22 0x00007ff7bc4c2bd4 std::invoke<<lambda_c9242529638530c2607074b83d50e781> > C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\type_traits:1586:0
2021-09-02T10:02:23.0446394Z 
2021-09-02T10:02:23.0446941Z #23 0x00007ff7bc4c1a78 std::thread::_Invoke<std::tuple<<lambda_c9242529638530c2607074b83d50e781> >,0> C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\thread:56:0
2021-09-02T10:02:23.0447320Z 
2021-09-02T10:02:23.0447640Z #24 0x00007ffa4e434c7c (C:\Windows\SYSTEM32\ucrtbased.dll+0x74c7c)
2021-09-02T10:02:23.0447794Z 
2021-09-02T10:02:23.0448087Z #25 0x00007ffa610e7974 (C:\Windows\System32\KERNEL32.DLL+0x17974)
2021-09-02T10:02:23.0448290Z 
2021-09-02T10:02:23.0448628Z #26 0x00007ffa61a2a2f1 (C:\Windows\SYSTEM32\ntdll.dll+0x5a2f1)

[MaskRay]

@andrewng Issue llvm_shutdown called by lld::exitLld(1) is racy is related to code touched by this patch. I wonder whether you have any insights...

lld/Common/ErrorHandler.cpp

ErrorHandler &lld::errorHandler() {
   return handler;
 }
 
 void lld::exitLld(int val) {
   // Delete any temporary file, while keeping the memory mapping open.
   if (errorHandler().outputBuffer)
     errorHandler().outputBuffer->discard();
 
-  // Dealloc/destroy ManagedStatic variables before calling
-  // _exit(). In a non-LTO build, this is a nop. In an LTO
-  // build allows us to get the output of -time-passes.
+  // Dealloc/destroy ManagedStatic variables before calling _exit().
+  // In an LTO build, allows us to get the output of -time-passes.
+  // Ensures that the thread pool for the parallel algorithms is stopped to
+  // avoid intermittent crashes on Windows when exiting.
   llvm_shutdown();
 
   lld::outs().flush();
   lld::errs().flush();
   _exit(val);
 }
 
 void lld::diagnosticHandler(const DiagnosticInfo &di) {

llvm/lib/Support/Parallel.cpp

 //===- llvm/Support/Parallel.cpp - Parallel algorithms --------------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #include "llvm/Support/Parallel.h"
 #include "llvm/Config/llvm-config.h"
+#include "llvm/Support/ManagedStatic.h"
 
 #if LLVM_ENABLE_THREADS
 
 #include "llvm/Support/Threading.h"
 
 #include <atomic>
+#include <future>
 #include <stack>
 #include <thread>
+#include <vector>
 
 namespace llvm {
 namespace parallel {
 namespace detail {
 
 namespace {
 
 /// An abstract class that takes closures and runs them asynchronously.
 class Executor {
 public:
   virtual ~Executor() = default;
   virtual void add(std::function<void()> func) = 0;
 
   static Executor *getDefaultExecutor();
 };
 
 /// An implementation of an Executor that runs closures on a thread pool
 ///   in filo order.
 class ThreadPoolExecutor : public Executor {
 public:
-  explicit ThreadPoolExecutor(unsigned ThreadCount = hardware_concurrency())
-      : Done(ThreadCount) {
+  explicit ThreadPoolExecutor(unsigned ThreadCount = hardware_concurrency()) {
     // Spawn all but one of the threads in another thread as spawning threads
     // can take a while.
-    std::thread([&, ThreadCount] {
-      for (size_t i = 1; i < ThreadCount; ++i) {
-        std::thread([=] { work(); }).detach();
+    Threads.reserve(ThreadCount);
+    Threads.resize(1);
+    std::unique_lock<std::mutex> Lock(Mutex);
+    Threads[0] = std::thread([&, ThreadCount] {
+      for (unsigned i = 1; i < ThreadCount; ++i) {
+        Threads.emplace_back([=] { work(); });
+        if (Stop)
+          break;
       }
+      ThreadsCreated.set_value();
       work();
-    }).detach();
+    });
   }
 
-  ~ThreadPoolExecutor() override {
+  void stop() {
     std::unique_lock<std::mutex> Lock(Mutex);
+    if (Stop)
+      return;
     Stop = true;
     Lock.unlock();
     Cond.notify_all();
-    // Wait for ~Latch.
+    ThreadsCreated.get_future().wait();
+  }
+
+  ~ThreadPoolExecutor() override {
+    stop();
+    std::thread::id CurrentThreadId = std::this_thread::get_id();
+    for (std::thread &T : Threads)
+      if (T.get_id() == CurrentThreadId)
+        T.detach();
+      else
+        T.join();
   }
 
+  struct Creator {
+    static void *call() { return new ThreadPoolExecutor(); }
+  };
+
+  struct Deleter {
+    static void call(void *Ptr) { ((ThreadPoolExecutor *)Ptr)->stop(); }
+  };
+
   void add(std::function<void()> F) override {
     std::unique_lock<std::mutex> Lock(Mutex);
     WorkStack.push(F);
     Lock.unlock();
     Cond.notify_one();
   }
 
 private:
   void work() {
     while (true) {
       std::unique_lock<std::mutex> Lock(Mutex);
       Cond.wait(Lock, [&] { return Stop || !WorkStack.empty(); });
       if (Stop)
         break;
       auto Task = WorkStack.top();
       WorkStack.pop();
       Lock.unlock();
       Task();
     }
-    Done.dec();
   }
 
   std::atomic<bool> Stop{false};
   std::stack<std::function<void()>> WorkStack;
   std::mutex Mutex;
   std::condition_variable Cond;
-  parallel::detail::Latch Done;
+  std::promise<void> ThreadsCreated;
+  std::vector<std::thread> Threads;
 };
 
 Executor *Executor::getDefaultExecutor() {
-  static ThreadPoolExecutor exec;
-  return &exec;
+  // The ManagedStatic enables the ThreadPoolExecutor to be stopped via
+  // llvm_shutdown() which allows a "clean" fast exit, e.g. via _exit(). This
+  // stops the thread pool and waits for any worker thread creation to complete
+  // but does not wait for the threads to finish. The wait for worker thread
+  // creation to complete is important as it prevents intermittent crashes on
+  // Windows due to a race condition between thread creation and process exit.
+  //
+  // The ThreadPoolExecutor will only be destroyed when the static unique_ptr to
+  // it is destroyed, i.e. in a normal full exit. The ThreadPoolExecutor
+  // destructor ensures it has been stopped and waits for worker threads to
+  // finish. The wait is important as it prevents intermittent crashes on
+  // Windows when the process is doing a full exit.
+  //
+  // The Windows crashes appear to only occur with the MSVC static runtimes and
+  // are more frequent with the debug static runtime.
+  //
+  // This also prevents intermittent deadlocks on exit with the MinGW runtime.
+  static ManagedStatic<ThreadPoolExecutor, ThreadPoolExecutor::Creator,
+                       ThreadPoolExecutor::Deleter>
+      ManagedExec;
+  static std::unique_ptr<ThreadPoolExecutor> Exec(&(*ManagedExec));
+  return Exec.get();
 }
 } // namespace
 
 static std::atomic<int> TaskGroupInstances;
 
 // Latch::sync() called by the dtor may cause one thread to block. If is a dead
 // lock if all threads in the default executor are blocked. To prevent the dead
 // lock, only allow the first TaskGroup to run tasks parallelly. In the scenario