<div dir="ltr">Based on a recent discussion[1], I started trying to remove the functions llvm_start_multithreaded() and llvm_stop_multithreaded() from the codebase.  It turns out this is a little bit tricky.  Consider the following scenario:<div>
<br></div><div>During program initialization, a global static object's constructor dereferences a ManagedStatic.  During dereferencing of the ManagedStatic, it needs to know whether or not to acquire the global lock in order to allocate the ManagedStatic</div>
<div><br></div><div>There are 3 possible types for the global_lock, and none of them solve the problem. </div><div><br></div><div>1) If global_lock is simply another global static, it may not have been constructed yet.</div>
<div><br></div><div>2) If global_lock is a raw pointer to a mutex, it would have to be explicitly allocated, and we can't guarantee this during static initialization.</div><div><br></div><div>3) If global_lock is a ManagedStatic<Mutex>, then it will get into an infinite recursion here when trying to allocate this ManagedStatic.</div>
<div><br></div><div>I actually started to feel this way since the first time I started looking at LLVM, but even moreso increasingly I feel that the solution is that ManagedStatics should not be allowed to be accessed until after main begins.   llvm_shutdown() gives deterministic order of destroying managed statics, but we don't have deterministic order of *creation* of those ManagedStatics.  I have a patch up[2] (still awaiting review) that shows a possible solution to these problems and how we might migrate the existing cases where this happens over to a ManagedStatic free static initialization.  </div>
<div><br></div><div>There is only one requirement: You must be able to insert a call very early in main() that will do the ManagedStatic initialization.  However, we can catch this with an assertion and all anyone would have to do is add one line to their main function.  As in [2], all this early main() code would do is copy fields over from one structure to another.  </div>
<div><br></div><div>As a side benefit, this provides the ability to "resurrect" after an llvm_shutdown(), shoudl that be desired, because the initial static state of the program always remains in-tact once main() is entered.</div>
<div><br></div><div>Thoughts?  Better ideas?</div><div><br><div><br></div><div>[1] - <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/073543.html">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/073543.html</a></div>
</div><div>[2] - <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140602/219684.html">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140602/219684.html</a></div></div>