8000 Add Condvar APIs not susceptible to spurious wake by vlovich · Pull Request #47970 · rust-lang/rust · GitHub
[go: up one dir, main page]

Skip to content

Add Condvar APIs not susceptible to spurious wake #47970

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

Merged
merged 9 commits into from
Feb 25, 2018
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Review response
Make condition closure accept mut T&.
Clarify spurious wakeup documentation.
Cleanup doc example code.
  • Loading branch information
Vitali Lovich committed Feb 2, 2018
commit e72bd6df5398dd7ee02c6057b861537c49649b4e
18 changes: 10 additions & 8 deletions src/libstd/sync/condvar.rs
Original file line number Diff line number Diff line change
Expand Up @@ -220,8 +220,9 @@ impl Condvar {
}

/// Blocks the current thread until this condition variable receives a
/// notification and the required condition is met. There are no spurious
/// wakeups when calling this.
/// notification and the required condition is met. Spurious wakeups are
/// ignored and this function will only return once the condition has been
/// met.
///
/// This function will atomically unlock the mutex specified (represented by
/// `guard`) and block the current thread. This means that any calls
Expand Down Expand Up @@ -260,14 +261,14 @@ impl Condvar {
/// // Wait for the thread to start up.
/// let &(ref lock, ref cvar) = &*pair;
/// // As long as the value inside the `Mutex` is false, we wait.
/// cvar.wait_until(lock.lock().unwrap(), |ref started| { started });
/// cvar.wait_until(lock.lock().unwrap(), |started| { started });
/// ```
#[stable(feature = "wait_until", since = "1.24")]
pub fn wait_until<'a, T, F>(&self, mut guard: MutexGuard<'a, T>,
mut condition: F)
-> LockResult<MutexGuard<'a, T>>
where F: FnMut(&T) -> bool {
while !condition(&*guard) {
where F: FnMut(&mut T) -> bool {
while !condition(&mut *guard) {
guard = self.wait(guard)?;
}
Ok(guard)
Expand Down Expand Up @@ -418,7 +419,8 @@ impl Condvar {
}

/// Waits on this condition variable for a notification, timing out after a
/// specified duration.
/// specified duration. Spurious wakes will not cause this function to
/// return.
///
/// The semantics of this function are equivalent to [`wait_until`] except
/// that the thread will be blocked for roughly no longer than `dur`. This
Expand Down Expand Up @@ -472,10 +474,10 @@ impl Condvar {
pub fn wait_timeout_until<'a, T, F>(&self, mut guard: MutexGuard<'a, T>,
mut dur: Duration, mut condition: F)
-> LockResult<(MutexGuard<'a, T>, WaitTimeoutResult)>
where F: FnMut(&T) -> bool {
where F: FnMut(&mut T) -> bool {
let timed_out = Duration::new(0, 0);
loop {
if !condition(&*guard) {
if !condition(&mut *guard) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This condition is backwards, right?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoops. It is. I can fix it or rewrite it as above (not sure which is simpler to read). Which would you prefer?

return Ok((guard, WaitTimeoutResult(false)));
} else if dur == timed_out {
return Ok((guard, WaitTimeoutResult(true)));
Expand Down
0