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

Document memory orderings of thread::{park, unpark} #99587

Merged
merged 6 commits into from
Jun 21, 2023
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
28 changes: 19 additions & 9 deletions library/std/src/thread/mod.rs
Original file line number Diff line number Diff line change
Expand Up @@ -845,7 +845,7 @@ pub fn sleep(dur: Duration) {
/// A call to `park` does not guarantee that the thread will remain parked
/// forever, and callers should be prepared for this possibility.
///
/// # park and unpark
/// # `park` and `unpark`
///
/// Every thread is equipped with some basic low-level blocking support, via the
/// [`thread::park`][`park`] function and [`thread::Thread::unpark`][`unpark`]
Expand All @@ -866,14 +866,6 @@ pub fn sleep(dur: Duration) {
/// if it wasn't already. Because the token is initially absent, [`unpark`]
/// followed by [`park`] will result in the second call returning immediately.
///
/// In other words, each [`Thread`] acts a bit like a spinlock that can be
m-ou-se marked this conversation as resolved.
Show resolved Hide resolved
/// locked and unlocked using `park` and `unpark`.
///
/// Notice that being unblocked does not imply any synchronization with someone
/// that unparked this thread, it could also be spurious.
/// For example, it would be a valid, but inefficient, implementation to make both [`park`] and
/// [`unpark`] return immediately without doing anything.
///
/// The API is typically used by acquiring a handle to the current thread,
/// placing that handle in a shared data structure so that other threads can
/// find it, and then `park`ing in a loop. When some desired condition is met, another
Expand All @@ -887,6 +879,23 @@ pub fn sleep(dur: Duration) {
///
/// * It can be implemented very efficiently on many platforms.
///
/// # Memory Orderings
m-ou-se marked this conversation as resolved.
Show resolved Hide resolved
///
ibraheemdev marked this conversation as resolved.
Show resolved Hide resolved
/// Calls to `park` _synchronize-with_ calls to `unpark`, meaning that memory
/// operations performed before a call to `unpark` are made visible to the thread that
/// consumes the token and returns from `park`. Note that all `park` and `unpark`
/// operations for a given thread form a total order and `park` synchronizes-with
/// _all_ prior `unpark` operations.
///
/// In atomic ordering terms, `unpark` performs a `Release` operation and `park`
/// performs the corresponding `Acquire` operation. Calls to `unpark` for the same
/// thread form a [release sequence].
///
ibraheemdev marked this conversation as resolved.
Show resolved Hide resolved
/// Notice that being unblocked does not imply any synchronization with someone that
/// unparked this thread, it could also be spurious. For example, it would be a valid,
/// but inefficient, implementation to make both park and unpark return immediately
/// without doing anything.
///
/// # Examples
///
/// ```
Expand Down Expand Up @@ -926,6 +935,7 @@ pub fn sleep(dur: Duration) {
///
/// [`unpark`]: Thread::unpark
/// [`thread::park_timeout`]: park_timeout
/// [release sequence]: https://en.cppreference.com/w/cpp/atomic/memory_order#Release_sequence
#[stable(feature = "rust1", since = "1.0.0")]
pub fn park() {
// SAFETY: park_timeout is called on the parker owned by this thread.
Expand Down