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-04-11 09:07:15 +02:00
parent 8e754e12c5
commit 0c3ec26b07
1 changed files with 10 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
man2/futex.2
View File

@ -59,16 +59,13 @@ in separate processes may be different,
the same physical address may be shared by the processes using
.BR mmap (2).)
When executing a
.BR futex ()
operation that requests to block a thread,
the kernel will only block if the futex word has the value that the
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 expected value.
The load from the futex word, the comparison with
the expected value,
and the actual blocking will happen atomically and totally
ordered with respect to concurrently executing
.BR futex ()
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; similar to an atomic
@ -88,14 +85,14 @@ using an atomic compare-and-exchange instruction.
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
representing the acquired state as the expected value to a
.BR futex ()
wait operation.
The call to
.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 a
.BR futex ()
lock state to not acquired and then execute a 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
@ -174,8 +171,8 @@ are as follows:
.\" commit 34f01cc1f512fa783302982776895c73714ebbc2
This option bit can be employed with all futex operations.
It tells the kernel that the futex is process-private and not shared
with another process (i.e., it is only being used for synchronization
between threads of the same process).
with another process (i.e., it is being used for synchronization
only between threads of the same process).
This allows the kernel to choose the fast path for validating
the user-space address and avoids expensive VMA lookups,
taking reference counts on file backing store, and so on.
@ -436,7 +433,7 @@ This operation was added as a replacement for the earlier
.BR FUTEX_REQUEUE .
The difference is that the check of the value at
.I uaddr
can be used to ensure that requeueing only happens under certain
can be used to ensure that requeueing happens only under certain
conditions.
Both operations can be used to avoid a "thundering herd" effect when
.B FUTEX_WAKE
@ -814,7 +811,7 @@ operation to release the lock.
In the cases where callers are forced into the kernel
(i.e., required to perform a
.BR futex ()
operation),
call),
they then deal directly with a so-called RT-mutex,
a kernel locking mechanism which implements the required
priority-inheritance semantics.