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

be more explicit about why adding backlinks eagerly makes sense

Browse Source
This commit is contained in:
joboet 2024-02-09 16:53:36 +01:00
parent 69f55de5ac
commit 3fa5a40737
No known key found for this signature in database
GPG Key ID: 704E0149B0194B3C
1 changed files with 7 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
library/std/src/sys/pal/unix/locks/queue_rwlock.rs
View File

@ -91,11 +91,12 @@
//!
//! Access to the queue is controlled by the `QUEUE_LOCKED` bit, which threads
//! try to set both after enqueuing themselves to eagerly add backlinks to the
//! queue and after unlocking the lock to wake the next waiter(s). This is done
//! atomically at the same time as the enqueuing/unlocking operation. The thread
//! releasing the `QUEUE_LOCK` bit will check the state of the lock and wake up
//! waiters as appropriate. This guarantees forward-progress even if the unlocking
//! thread could not acquire the queue lock.
//! queue, which drastically improves performance, and after unlocking the lock
//! to wake the next waiter(s). This is done atomically at the same time as the
//! enqueuing/unlocking operation. The thread releasing the `QUEUE_LOCK` bit
//! will check the state of the lock and wake up waiters as appropriate. This
//! guarantees forward-progress even if the unlocking thread could not acquire
//! the queue lock.
//!
//! ## Memory orderings
//!
@ -358,7 +359,7 @@ impl RwLock {
} else {
// Otherwise, the tail of the queue is not known.
node.tail.set(None);
// Try locking the queue to fully link it.
// Try locking the queue to eagerly add backlinks.
next = next.map_addr(|addr| addr | QUEUE_LOCKED);
}