futex.2: Cut down discussion of FUTEX_REQUEUE; defer to FUTEX_CMP_REQUEUE

FUTEX_CMP_REQUEUE supercedes FUTEX_REQUEUE and provides a superset
of its functionality. There is need to duplicate any details in
the FUTEX_REQUEUE description, simple defer to the
FUTEX_CMP_REQUEUE and note the differences. This also guides the
reader to do the right thing: use FUTEX_CMP_REQUEUE rather than
FUTEX_REQUEUE.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2015-01-13 06:59:13 +01:00
parent 3dfcc11d46
commit dd05d61221
1 changed files with 7 additions and 25 deletions

View File

@ -432,36 +432,18 @@ has been removed from Linux 2.6.26 onward.
.\"
.\" FIXME I added this warning. Okay?
.IR "Avoid using this operation" .
It is broken (unavoidably racey) for its intended purpose.
It is broken (unavoidably racy) for its intended purpose.
Use
.BR FUTEX_CMP_REQUEUE
instead.
This operation was introduced in order to avoid a "thundering herd" effect
when
.B FUTEX_WAKE
is used and all processes woken up need to acquire another futex.
The argument
.I val
contains the number of waiters on
.I uaddr
that are immediately woken up.
The
.I timeout
argument is (ab)used to specify the number of waiters
that are requeued to the futex at
.IR uaddr2 ;
the kernel casts the
.I timeout
value to
.IR u32 .
.\" FIXME What are the constraints (if any) on the values of 'val' vs
.\" 'timeout' vs [the number of waiters on 'uaddr']?
The argument
This operation performs the same task as
.BR FUTEX_CMP_REQUEUE ,
except that no check is made using the value in
.IR val3 .
(The argument
.I val3
is ignored.
is ignored.)
.TP
.BR FUTEX_CMP_REQUEUE " (since Linux 2.6.7)"
This operation was added as a replacement for the earlier