Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Making detail::condition_variable safe to use #1519

Merged
merged 3 commits into from May 21, 2015
Merged

Making detail::condition_variable safe to use #1519

merged 3 commits into from May 21, 2015

Conversation

K-ballo
Copy link
Member

@K-ballo K-ballo commented May 17, 2015

Minor redesign of how locks are handled by detail::condition_variable:

Since #1488, the semantics of locks used with detail::cv where changed in a way that is difficult to handle correctly with Lockables that do not represent ownership. To avoid this fragile scenario, detail::cv now only accepts `boost::unique_lock`s, which are known to be safe.
… to make the new requirements of detail::cv explicit
Calls to detail::cv notification functions will now always leave the lock unlocked. Reacquiring the lock is often unnecessary, and leaving it unlocked gives the notified thread a better chance to resume work immediately rather than having to wait for a locked mutex.

To make the transfer of the lock ownership explicit, those functions now take the lock by value.
@hkaiser
Copy link
Member

hkaiser commented May 18, 2015

LGTM

K-ballo added a commit that referenced this pull request May 21, 2015
Making detail::condition_variable safe to use
@K-ballo K-ballo merged commit 289f98a into master May 21, 2015
@K-ballo K-ballo deleted the cv-locks branch May 21, 2015 00:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants