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

[Zachary Turner]

Regarding the assertions, they are only fired with specific mutex objects,
in particular if you never use a [Recursive/NonRecursive]DebugMutex, it
will never assert.  So the solution to that particular problem is just
always use RecursiveMutex and NonRecursiveMutex.  If you look at
lib\Support\Mutex.h right now, those classes don't exist.  I'm referring to
the names that I gave them in my patch to make the llvm mutex use
std::mutex  (which you can see here: http://reviews.llvm.org/D4033).


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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140605/d55672b9/attachment.html>