This is an archive of the discontinued LLVM Phabricator instance.

second pass over removal of Mutex and Condition
ClosedPublic

Authored by compnerd on May 17 2016, 9:56 PM.

Details

Reviewers
zturner
clayborg
Summary

A second pass to remove use of Mutex and Condition. This removes cases where the mutex may be shared outside of the class or may be conditionally locked. With this patch applied the current remaining uses are limited to uses involving Condition and in the GDBCommunication code path where there is a helper mutex class. The third class of usage is DenseSet and DenseMap which allow the user to specify the mutex type (this may require a bit more tweak, template parameter is the approach which comes to mind).

The Condition changes will require changing TimeVal to chromo::duration, but we should be able to do that as well.

After this patch, I believe that there are only a handful of instances where we use the lldb_private::Mutex (~5) and the associated locations for Mutex::Locker.

Diff Detail

Event Timeline

compnerd updated this revision to Diff 57559.May 17 2016, 9:56 PM
compnerd retitled this revision from to second pass over removal of Mutex and Condition.
compnerd updated this object.
compnerd added reviewers: clayborg, zturner.
compnerd set the repository for this revision to rL LLVM.
compnerd added a subscriber: lldb-commits.
zturner accepted this revision.May 18 2016, 11:15 AM
zturner edited edge metadata.

Looks good on Windows with the two suggested fixes.

source/Interpreter/CommandObject.cpp
339
if (m_api_locker)
    m_api_locker.unlock();

Otherwise this is undefined behavior. Also make sure you do this check anywhere else in the patch where you do manual unlocking / locking like this.

source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
404

change this to auto interpreter_lock so it doesn't redefine lock from line 186

This revision is now accepted and ready to land.May 18 2016, 11:15 AM
compnerd marked 2 inline comments as done.May 18 2016, 6:19 PM
compnerd added inline comments.
source/Interpreter/CommandObject.cpp
339

Yeah, this was the only place where the lock was unlocked and there wasn't a comment indicating that the assumption was that the lock will be held. A few places where there were unlocks were early releases of the unique_lock. A couple of places indicated that the lock must have been acquired prior to the destructor running.

compnerd closed this revision.May 18 2016, 10:21 PM
compnerd marked an inline comment as done.

SVN r270024.