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

[Zachary Turner]

Perhaps not.  It might not even be valuable for LLVM, as the wrapper is
only useful for enabling this debug functionality (assertions), but I took
the path of least resistance and made the semantics identical.

Still, assuming the wrapper is valuable for LLVM, then I think there's
inherent value in having LLDB use LLVM's mutex rather than using std::mutex
natively just for code reuse, and then enhancing LLVM's mutex wrapper to
support LLDB's use cases.  LLDB aleady does things like logging its mutex
accesses etc, so these are the perfect types of tasks for a wrapper class.


On Thu, Jun 5, 2014 at 5:32 PM, Reid Kleckner <rnk at google.com> wrote:

> 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/4a5a79ab/attachment.html>