Skip to content

Commit 9ad3754

Browse files
Rollup merge of rust-lang#52771 - matklad:patch-1, r=kennytm
Clarify thread::park semantics It took me quite some time to realize that the example is not actually racy, so let's clarify it? :-)
2 parents 7eb7175 + 5f87f78 commit 9ad3754

File tree

1 file changed

+4
-1
lines changed

1 file changed

+4
-1
lines changed

src/libstd/thread/mod.rs

+4-1
Original file line numberDiff line numberDiff line change
@@ -731,7 +731,8 @@ const NOTIFIED: usize = 2;
731731
/// specifying a maximum time to block the thread for.
732732
///
733733
/// * The [`unpark`] method on a [`Thread`] atomically makes the token available
734-
/// if it wasn't already.
734+
/// if it wasn't already. Because the token is initially absent, [`unpark`]
735+
/// followed by [`park`] will result in the second call returning immediately.
735736
///
736737
/// In other words, each [`Thread`] acts a bit like a spinlock that can be
737738
/// locked and unlocked using `park` and `unpark`.
@@ -766,6 +767,8 @@ const NOTIFIED: usize = 2;
766767
/// // Let some time pass for the thread to be spawned.
767768
/// thread::sleep(Duration::from_millis(10));
768769
///
770+
/// // There is no race condition here, if `unpark`
771+
/// // happens first, `park` will return immediately.
769772
/// println!("Unpark the thread");
770773
/// parked_thread.thread().unpark();
771774
///

0 commit comments

Comments
 (0)