[PATCH] Removing the static destructor from ManagedStatic.cpp by controlling the allocation and de-allocaation of the mutex.

[Reid Kleckner]

================
Comment at: lib/Support/ManagedStatic.cpp:30
@@ -29,1 +29,3 @@
+  if (nullptr == ManagedStaticMutex)
+    ManagedStaticMutex = new sys::Mutex();
   return ManagedStaticMutex;
----------------
chandlerc wrote:
> beanz wrote:
> > chandlerc wrote:
> > > Uh... How is this safe? How does this bootstrap when it is called while acquiring a lock (and thus concurrently without any other synchronization)?
> > It isn't, but since MSVC doesn't implement thread-safe static local initialization I figured this wasn't any worse off.
> > 
> > Do you have an alternate suggestion? I know in other places in LLVM we avoid the static destructor by just leaking the pointer (which I don't like). I could also static init the pointer, and still control deleting it, but I'm not sure that gets us much.
> > 
> > Thoughts?
> I don't know how we've not been bitten by this before. It certainly was always unsafe on Windows, but historically was safe on Linux and Mac. =/
> 
> I think the correct fix here is to just platform specific code here. Rewrite this as an initialization function, and then use pthreads if we have it or C++11 if not (so MinGW's defective C++11 <mutex> and <thread> implementation can be coped with) to do a 'run_once' or 'once_init' or however it is spelled in a threadsafe way.
> 
> I'm happy to "leak" the single mutex provided we initialize it in a thread safe way.
The problematic platform is MinGW with native win32 threads. This platform has neither pthreads nor C++11 <mutex>. The only way to implement initialization here is to use the native win32 one-time initialization:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686934(v=vs.85).aspx

I think I have the right bits to test this configuration now. If you send a patch I can fill in the blanks and send it back.

http://reviews.llvm.org/D5473