Page MenuHomePhabricator

Clean up vestigial remnants of locking primitives

Authored by compnerd on May 19 2016, 8:20 AM.



This finally removes the use of the Mutex and Condition classes. This is an
intricate patch as the Mutex and Condition classes were tied together.
Furthermore, many places had slightly differing uses of time values. Convert
timeout values to relative everywhere to permit the use of
std::chrono::duration, which is required for the use of
std::condition_variable's timeout. Adjust all Condition and related Mutex
classes over to std::{,recursive_}mutex and std::condition_variable.

This change primarily comes at the cost of breaking the TracingMutex which was
based around the Mutex class. It would be possible to write a wrapper to
provide similar functionality, but that is beyond the scope of this change.

Diff Detail

Event Timeline

compnerd updated this revision to Diff 57799.May 19 2016, 8:20 AM
compnerd retitled this revision from to Clean up vestigial remnants of locking primitives.
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.
clayborg accepted this revision.May 19 2016, 10:13 AM
clayborg edited edge metadata.

We should think about converting everyone over to using std::chrono::microseconds for any timeout parameters that are currently "uint32_t timeout_usec". But we can do that in a future change.


Should we convert the "timeout_usec" argument over to be a std::chrono::microseconds type?

This revision is now accepted and ready to land.May 19 2016, 10:13 AM

Yeah, I was thinking that once this clean up is done, we should remove the use of TimeValue in favor of std::chrono::duration.

zturner edited edge metadata.May 19 2016, 3:28 PM
zturner added a subscriber: zturner.

I can try this on Windows tomorrow

I'm still getting a lot of crashes after this, but this will at least fix the compiler errors. I will try to look at the crashes on Monday.


Need to use auto here, otherwise there's a compiler error.


this needs to use std::chrono::duration_cast<std::chrono::microseconds>(until - std::chrono::system_clock::now()). Maybe raise this into a temporary variable (also make sure to use auto on the result just in case).


duration_cast again.


Delete the cast here. Just use std::chrono::system_clock::now().


Change to timeout.time_since_epoch()

Here is a patch you can apply on top of your patch to fix the compiler and
runtime errors (on Windows at least).

Most of the compiler errors were around the use of duration_cast. I've
never used std::chrono before, but my best guess is that system_time::now()
is a different type on Windows and other platforms, and so explicitly
specifying the type to store it to results in implicit conversion errors.
Apparently this is exactly what duration_cast is for, so I used it.

There was a semantic change in the event handler that caused runtime
errors. Basically in WaitForEventsInternal() if it didn't find an event
the first time, it would wait for a condition variable, then try again.
But in the changed code, it would wait for a condition variable and then
immediately return failure without retrying. So I fixed this and
everything seems to be going smooth.I would encourage Greg or someone else
to actually test this on OSX, but at least on Windows it looks good with
the attached patch.

I think will be good idea to try to commit these changes before 3.9 branching.

Ugh, yeah, I had forgotten about this. Ill try to get to this tonight/tomorrow.


Yeah, noticed that on Linux; Ill upload a new version of the patch. I ended up just doing the math in a second step.


Yeah, hoisting that into a local var sounds good.






This doesn't work for me. timeout is a std::duration, and std::time_point is needed.

compnerd updated this revision to Diff 64446.Jul 18 2016, 10:47 PM
compnerd edited edge metadata.
compnerd removed rL LLVM as the repository for this revision.

Updated to the current tree.

Tested against Linux-x86_64, tests state seems unchanged across the patch. @zturner you want to run another round on Windows before I merge this?

compnerd updated this revision to Diff 64448.Jul 18 2016, 10:51 PM
emaste added a subscriber: emaste.Jul 19 2016, 6:20 AM

I'm testing on FreeBSD now

With this patch, test results on FreeBSD are consistent.

Is this ready to be committed?

compnerd added a subscriber: sas.Jul 26 2016, 6:51 PM

@emaste I think so. I was hoping that @zturner or @sas would be able to get a windows run. However, Linux and FreeBSD should give us some assurance that this is good. How about I go ahead and commit this tomorrow?

compnerd closed this revision.Jul 28 2016, 5:45 PM

SVN r277011