[PATCH] Change base mutex implementations to use STL-provided mutexes

Aaron Ballman aaron.ballman at gmail.com
Sat Jun 7 07:19:07 PDT 2014


On Fri, Jun 6, 2014 at 9:06 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
> Backing up a second, and setting aside all aspects of windows.h, I think
> this patch is going in the wrong direction at a very fundamental level.
>
> I think it is a really huge mistake for LLVM to continue to use its own
> Mutex class. I don't think you should change it, I think you should remove
> it, and use std::mutex. I understand that this may be hard, but I think time
> would be better spent working on those hard problems. I see a few elements
> that you'll need to address:
> 1) Fixing the code in atexit handlers. I'm not 100% certain of the right
> approach here, but my strong suspicion is that they should not be using a
> mutex *at all*. LLVM should have *very* little code in atexit handlers as a
> library, and that code really should be customized for the single threaded
> and strange circumstance in which it runs. I know you've already started
> down this path. In general, that should be a nice separable bit.
>
> 2) You or someone else should start a discussion on llvmdev@ about whether
> or not we need to avoid the *overhead* of an uncontended mutex lock when
> LLVM is not multithreaded. I think that the answer is "no" based on a lot of
> experience with reasonably good mutex implementations, but we need to
> collect more opinions about this and understand the specific use cases. If
> there are mutexes which materially impact the performance of LLVM when
> running in a single thread, they will also be performance problems for
> multithreaded code (by virtue of crazy amounts of contention) and should be
> fixed directly.
>
> 3) Perhaps even before doing #2, we should sort out whether the
> multithreaded support in LLVM should be a compile time or runtime parameter.
> While I strongly feel it should be compile time if present at all, this
> isn't a discussion for a long, twisty patch review thread. =] It needs its
> own discussion and a wider audience.
>
>
> I also suspect you could go ahead and convert some users of mutexes to
> std::mutex while these things are in-flight. For example, I agree with Greg
> who said on the LLDB list that he would prefer LLDB just use std::mutex --
> why not go ahead and start that migration? If LLD still uses something else,
> that would be another good candidate. Both of those have a decent history of
> being multithreaded always, and so it seems uncontentious there even while
> we try to sort out exactly what is right for the core libraries that support
> JITs and other more complex users.

I assumed that unifying semantics was the initial goal, and replacing
with std::mutex was the ultimate goal (kind of like how we went about
the OwningPtr -> unique_ptr refactoring). So I agree with the approach
you've laid out here.

~Aaron



More information about the llvm-commits mailing list