[lldb-dev] Replacing mutex with llvm::Mutex

Reid Kleckner rnk at google.com
Thu Jun 5 17:32:42 PDT 2014

Since LLDB doesn't use the questionable "is multithreading enabled"
functionality of LLVM's mutexes, I think it could probably get away with
std::mutex, depending on the existing usage.

Do you the the wrapper is really valuable for LLDB?

On Thu, Jun 5, 2014 at 5:16 PM, Zachary Turner <zturner at google.com> wrote:

> Just to be clear, std::mutex *is* the C++11 mutex, so what you're saying
> is the same as what I'm proposing.  It's just that in llvm they are wrapped
> inside of an additional class, to provide some very lightweight diagnostics
> code.
> On Thu, Jun 5, 2014 at 4:58 PM, Greg Clayton <gclayton at apple.com> wrote:
>> > On Jun 5, 2014, at 2:54 PM, Zachary Turner <zturner at google.com> wrote:
>> >
>> > I have some patches up to LLVM currently to replace their base mutex
>> implementations with std::mutex and std::recursive_mutex.  Assuming those
>> go through, the next logical step would be to replace LLDB's mutex
>> implementation with llvm::Mutex.
>> Why not just switch to the C++11 mutexes? We should get rid of the
>> llvm::Mutex and the lldb_private::Mutex and rely on the C++11 versions.
>> > I've had a look through the code, and the biggest feature that will be
>> difficult to reproduce under this implementation is that of logging
>> specific error messages from the pthread_mutex functions.  STL's
>> implementation of course uses C++ exceptions, which both LLDB and LLVM
>> disable at compile time.  In general, I don't expect that this will be very
>> problematic, because errors to lock and unlock typically indicate an
>> invalid use of the mutex, which shoudl be caught during development time,
>> and errors to try_lock() are almost always "the mutex was already locked',
>> in which case you only need a bool.
>> >
>> > Before I go down this path, I want to find out if anyone has urgent
>> need of this logging information in a way that is not upstreamable into
>> LLVM, or if they can think of any other reasons I should not attempt this.
>> >
>> > In general though, I think it would be a good idea to move more common
>> stuff down to LLVM and make use of it there, whenever possible.
>> I would like to see both llvm and LLDBs mutex objects go away and we
>> should switch over to C++11.
>> LLVM and clang is not heavily multi-threaded and they have asserts (see
>> llvm/lib/Support/Mutex.cpp) in the code that will cause LLDB to crash when
>> run under Xcode or from the command line when/if anything goes wrong (we
>> have similar asserts, but we enable them only for development) and we can't
>> have the assertions firing off and crashing Xcode or command line LLDB.
>> Also, switching to std::mutex and std::recursive_mutex just will make
>> things slower (since they are based on the same underlying pthread calls)
>> and it also introduce exceptions that get thrown when/if things go wrong?
>> It we aren't switching to C++11, I would rather not change at all, and if
>> we switch to C++11 we need to make sure no exceptions will get thrown or we
>> can't switch.
>> Greg
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140605/43cab732/attachment.html>

More information about the lldb-dev mailing list