LDP
/
man-pages
mirror of https://github.com/mkerrisk/man-pages
0
1
Fork 0
Code Releases Activity

futex.2: explanation of blocking 

Use shorter sentences.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Heinrich Schuchardt 2015-03-29 21:13:03 +02:00 committed by Michael Kerrisk
parent b80daba225
commit 8e754e12c5
1 changed files with 11 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
man2/futex.2
View File

@ -85,14 +85,18 @@ In the uncontended case,
a thread can access or modify the lock state with atomic instructions,
for example atomically changing it from not acquired to acquired
using an atomic compare-and-exchange instruction.
If a thread cannot acquire a lock because
it is already acquired by another thread,
it can request to block if and only the lock is still acquired by
using the lock's flag as futex word and expecting a value that
represents the acquired state.
A thread maybe unable acquire a lock because
it is already acquired by another thread.
It then may pass the lock's flag as futex word and the value
representing the acquired state as expected value to a
.BR futex ()
wait operation.
.BR futex ()
will block if and only if the lock is still acquired.
When releasing the lock, a thread has to first reset the
lock state to not acquired and then execute the futex operation that
wakes one thread blocked on the futex word that is the lock's flag
lock state to not acquired and then execute a
.BR futex ()
operation that wakes threads blocked on the lock flag used as futex word.
(this can be be further optimized to avoid unnecessary wake-ups).
See
.BR futex (7)