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

futex.2: Minor wording fixes 

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2015-07-28 10:51:45 +02:00
parent b0f35fbb09
commit 55f9e85ead
1 changed files with 13 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
man2/futex.2
View File

@ -73,7 +73,9 @@ but these addresses all refer to the same location in physical memory.)
When executing a futex operation that requests to block a thread,
the kernel will block only if the futex word has the value that the
calling thread supplied as the expected value of the futex word.
calling thread supplied (as one of the arguments of the
.BR futex ()
call) as the expected value of the futex word.
The loading of the futex word's value,
the comparison of that value with the expected value,
and the actual blocking will happen atomically and totally
@ -81,7 +83,7 @@ ordered with respect to concurrently executing futex
operations on the same futex word.
Thus, the futex word is used to connect the synchronization in user space
with the implementation of blocking by the kernel.
Like an atomic
Analogously to an atomic
compare-and-exchange operation that potentially changes shared memory,
blocking via a futex is an atomic compare-and-block operation.
.\" FIXME(Torvald Riegel):
@ -90,25 +92,27 @@ blocking via a futex is an atomic compare-and-block operation.
.\" See NOTES for
.\" a detailed specification of the synchronization semantics.
One example use of futexes is implementing locks.
One example use of futexes is for implementing locks.
The state of the lock (i.e., acquired or not acquired)
can be represented as an atomically accessed flag in shared memory.
In the uncontended case,
a thread can access or modify the lock state with atomic instructions,
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.
A thread may be unable to acquire a lock because
(Such instructions are performed entirely in user mode,
and the kernel maintains no information about the lock state.)
On the other hand, a thread may be unable to 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
It then may pass the lock's flag as a futex word and the value
representing the acquired state as the expected value to a
.BR futex ()
wait operation.
The call to
This
.BR futex ()
will block if and only if the lock is still acquired.
call 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 a futex
operation that wakes threads blocked on the lock flag used as futex word
operation that wakes threads blocked on the lock flag used as a futex word
(this can be be further optimized to avoid unnecessary wake-ups).
See
.BR futex (7)