Add notes about memory ordering to futex parker implementation.
This commit is contained in:
parent
485f882d77
commit
4301b5c1cc
1 changed files with 20 additions and 0 deletions
|
@ -11,6 +11,26 @@ pub struct Parker {
|
||||||
state: AtomicI32,
|
state: AtomicI32,
|
||||||
}
|
}
|
||||||
|
|
||||||
|
// Notes about memory ordering:
|
||||||
|
//
|
||||||
|
// Memory ordering is only relevant for the relative ordering of operations
|
||||||
|
// between different variables. Even Ordering::Relaxed guarantees a
|
||||||
|
// monotonic/consistent order when looking at just a single atomic variable.
|
||||||
|
//
|
||||||
|
// So, since this parker is just a single atomic variable, we only need to look
|
||||||
|
// at the ordering guarantees we need to provide to the 'outside world'.
|
||||||
|
//
|
||||||
|
// The only memory ordering guarantee that parking and unparking provide, is
|
||||||
|
// that things which happened before unpark() are visible on the thread
|
||||||
|
// returning from park() afterwards. Otherwise, it was effectively unparked
|
||||||
|
// before unpark() was called while still consuming the 'token'.
|
||||||
|
//
|
||||||
|
// In other words, unpark() needs to synchronize with the part of park() that
|
||||||
|
// consumes the token and returns.
|
||||||
|
//
|
||||||
|
// This is done with a release-acquire synchronization, by using
|
||||||
|
// Ordering::Release when writing NOTIFIED (the 'token') in unpark(), and using
|
||||||
|
// Ordering::Acquire when checking for this state in park().
|
||||||
impl Parker {
|
impl Parker {
|
||||||
#[inline]
|
#[inline]
|
||||||
pub const fn new() -> Self {
|
pub const fn new() -> Self {
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue