This is an archive of the discontinued LLVM Phabricator instance.

Thread safety analysis: Support deferring locks
ClosedPublic

Authored by aaronpuchert on Jun 6 2020, 5:53 AM.

Details

Summary

The standard std::unique_lock can be constructed to manage a lock without
initially acquiring it by passing std::defer_lock as second parameter.
It can be acquired later by calling lock().

To support this, we use the locks_excluded attribute. This might seem
like an odd choice at first, but its consistent with the other
annotations we support on scoped capability constructors. By excluding
the lock we state that it is currently not in use and the function
doesn't change that, which is exactly what the constructor does.

Along the way we slightly simplify handling of scoped capabilities.

Diff Detail

Event Timeline

aaronpuchert created this revision.Jun 6 2020, 5:53 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 6 2020, 5:53 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
aaron.ballman accepted this revision.Jun 8 2020, 5:57 AM

LGTM! Should we update the public docs for this change as well? Specifically, I am wondering if we should update https://clang.llvm.org/docs/ThreadSafetyAnalysis.html#mutexheader

This revision is now accepted and ready to land.Jun 8 2020, 5:57 AM

LGTM! Should we update the public docs for this change as well? Specifically, I am wondering if we should update https://clang.llvm.org/docs/ThreadSafetyAnalysis.html#mutexheader

Yes, some existing functionality seems undocumented as well (like adopting locks), which is why I was planning a bigger change.

My plan is basically to go through the test cases (which seem to be quite complete in terms of what we intend to support) and see what deserves mention in the official docs.

This revision was automatically updated to reflect the committed changes.