[LLVMdev] Multi-threading and mutexes in LLVM

[Zachary Turner]

I'm reviving this thread because I have a new patch ready to go that
attempts to push this through again.

http://reviews.llvm.org/D4223

The last time, there were a couple of major issues that came up during
review, outlined in the original post of this thread.  All of those have
been addressed in already-submitted patches.

One additional concern was expressed offline, which is simply to make sure
that this change does not cause a significant performance regression in the
single-threaded case.  I have run wall-clock comparisons on Windows and Mac
OSX of compiling a very large TU that showed no noticeable difference, so I
believe that concern has been addressed as well.

Feel free to discuss here or offer comments on the review, but I wanted to
make sure the community is aware that I'm attempting to push this through
again, in case anyone has concerns that have yet to be addressed.

Zach


On Mon, Jun 9, 2014 at 3:58 AM, Mathias Fröhlich <Mathias.Froehlich at web.de>
wrote:

>
> Hi,
>
> On Saturday, June 07, 2014 10:26:29 Aaron Ballman wrote:
> > > 1) Should support multi-threading be a compile-time or runtime
> parameter in
> > > LLVM?
> > >
> > > Currently it is both.  It is compile-time through the use of the define
> > > LLVM_ENABLE_THREADS, and it is runtime through the use of functions
> > > llvm_start_multithreaded, llvm_is_multithreaded, etc.  I and some
> others
> > > feel like runtime support for multi-threading could be removed, and it
> > > should be compile-time only.  However, I am not aware of all the ways
> in
> > > which this is being used, so this is where I would like some feedback.
>  The
> > > issues I have with runtime multithreading support are the following:
> > >
> > > * It leads to confusing code.  At any given point, is multi-threading
> > > enabled or disabled?  You never know without calling
> llvm_is_multithreaded,
> > > but even calling that is inherently racy, because someone else could
> disable
> > > it after it returns.
> > >
> > > * It leads to subtle bugs.  clang_createIndex, the first time it's
> called,
> > > enables multi-threading.  What happens if someone else disables it
> later?
> > > Things like this shouldn't even be possible.
> > >
> > > * Not all platforms even support threading to begin with.  This works
> now
> > > because llvm_start_multithreaded(), if the compile time flag is set to
> > > disable threads, simply does nothing.  But this decision should be
> made by
> > > someone else.  Nobody really checks the return value from
> > > llvm_start_multithreaded anyway, so there's already probably bugs where
> > > someone tries to start multi-threading, and it fails.
> > >
> > > * What does it actually mean to turn multi-threading support on and
> off?
> > >
> > > Anybody that tries to do this is almost certainly broken due to some
> edge
> > > cases about when it's on and when it's off.  So this goes back to the
> first
> > > two points about confusing code and subtle bugs.
> >
> > I agree with your assessment, and my personal feeling is that this
> > should be a compile-time switch. Code which attempts to do this at
> > runtime often has subtle bugs.
>
> Just to make you aware of a use case scenario that strikes me since some
> time
> together with the open source OpenGL driver stack that makes use of llvm.
>
> There you see driver modules which potentially get loaded anywhere at
> application run time. Potentially this can happen from any thread (even if
> in
> reality probably serialized by the dynamic loader) and thus can also race
> against
> the main application itself calling llvm_start_multithreaded in an other
> thread.
> Or if I remember correctly as documented, llvm_start_multithreaded must
> not be
> called concurrently to any other llvm api calls possibly accessing any of
> the llvm singeltons. Which in turn is hard to guarantee if you get
> dynamically
> loaded at run time and you have to expect the main application to use llvm
> already.
>
> Given that I would wish that you can just make use of llvm concurrently
> and having
> that no option at all, but I can easily anticipate the usual resistance
> against that.
>
> Nevertheless if multithreading is a compile option, it would be great if a
> user
> of llvm can see if the llvm libraries have been compiled with
> multithreading
> enabled or not. Probably best queriable at runtime so that a potential
> user can bail out in a nice way instead of just crashing later ...
>
> So it would be good if you keep this use case in mind when doing changes
> in this corner!
>
> Thanks
>
> Mathias
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140619/b226a8cd/attachment.html>