mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

expand thread::park explanation

Browse Source
This commit is contained in:
Ralf Jung 2018-11-22 10:54:04 +01:00
parent 4bec59c93b
commit 2d46ae7c37
1 changed files with 6 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
src/libstd/thread/mod.rs
View File

@ -806,9 +806,13 @@ pub fn sleep(dur: Duration) {
/// In other words, each [`Thread`] acts a bit like a spinlock that can be
/// locked and unlocked using `park` and `unpark`.
///
/// Notice that it would be a valid (but inefficient) implementation to make both [`park`] and
/// [`unpark`] NOPs that return immediately. Being unblocked does not imply
/// any synchronization with someone that unparked this thread, it could also be spurious.
///
/// 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. When some desired condition is met, another
/// find it, and then `park`ing in a loop. When some desired condition is met, another
/// thread calls [`unpark`] on the handle.
///
/// The motivation for this design is twofold:
@ -829,6 +833,7 @@ pub fn sleep(dur: Duration) {
/// .spawn(|| {
/// println!("Parking thread");
/// thread::park();
/// // We *could* get here spuriously, i.e., way before the 10ms below are over!
/// println!("Thread unparked");
/// })
/// .unwrap();