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

[Greg Clayton]

> 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