[LLVMdev] Multi-threading and mutexes in LLVM

[Mathias Fröhlich]

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