[PATCH] Change the LLVM global lock to use RAII semantics

Zachary Turner zturner at google.com
Fri Jun 13 17:17:55 PDT 2014


================
Comment at: lib/Support/Threading.cpp:25
@@ +24,3 @@
+sys::Mutex &llvm::llvm_get_global_lock() {
+  static sys::Mutex global_lock;
+  return global_lock;
----------------
Chandler Carruth wrote:
> Is the constructor for a mutex threadsafe? Because we use VS versions which don't provide a thread safe initialization. Actually, even if the constructor is threadsafe, won't that still form a data race if we call this from two threads when built with MSVC?
> 
> I think you'll need this to be a static global ultimately... =/
I should probably put a comment here, but the problem with that is that static constructors can trigger instantiation of ManagedStatics.  In this particular CL, that will be fine, because when a ManagedStatic is instantiated during a static constructor, llvm_is_multithreaded() will be false.

But after the rest goes through, multi-threading will always be on, and if the mutex is a global static we won't be able to guarantee that the mutex's constructor will have been called.  By definining it in the function, we can enforce the ordering.

By the same logic though, since we call this from static constructors, we know that it will be initialized in a thread-safe fashion.  But this is only by chance (since we know we use static constructors), so perhaps we should leave a comment indicating this so that if / when we get entirely rid of static constructors, we will know to go back and fix this.

http://reviews.llvm.org/D4142






More information about the llvm-commits mailing list