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

futex.2: Remove warning that FUTEX_REQUEUE is broken 

Darren Hart pointed me to the comments from Rich Felker
that there are valid use cases for FUTEX_REQUEUE.

    From: Rich Felker <dalias@libc.org>
    Date: Wed, 29 Oct 2014 22:43:17 -0400
    To: Darren Hart <dvhart@infradead.org>
    Cc: GLIBC Devel <libc-alpha@sourceware.org>, ...
    Subject: Re: Add futex wrapper to glibc?

    On Wed, Oct 29, 2014 at 06:59:15PM -0700, Darren Hart wrote:
    [...]
    > I wonder though... can we not wrap FUTEX_REQUEUE? It's fundamentally
    > broken.  FUTEX_CMP_REQUEUE should *always* be used instead. The glibc
    > wrapper is one way to encourage developers to do the right thing
    > (don't expose the bad op in the header).

    You're mistaken here. There are plenty of valid ways to use
    FUTEX_REQUEUE - for example if the calling thread is requeuing the
    target(s) to a lock that the calling thread owns. Just because it
    doesn't meet the needs of the way glibc was using it internally
    doesn't mean it's useless for other applications.

Reported-by: Darren Hart <dvhart@infradead.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2015-07-30 09:17:53 +02:00
parent da56650ae4
commit 27dd3a6e79
1 changed files with 11 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
man2/futex.2
View File

@ -396,22 +396,9 @@ from Linux 2.6.26 onward.
.\"
.TP
.BR FUTEX_REQUEUE " (since Linux 2.6.0)"
.\" Strictly speaking: from Linux 2.5.70
.\" FIXME(Torvald) Is there some indication that FUTEX_REQUEUE is broken
.\" in general, or is this comment implicitly speaking about the
.\" condvar (?) use case? If the latter we might want to weaken the
.\" advice below a little.
.\" [Anyone else have input on this?]
.\"
.IR "Avoid using this operation" .
It is broken for its intended purpose.
Use
.BR FUTEX_CMP_REQUEUE
instead.
This operation performs the same task as
.BR FUTEX_CMP_REQUEUE ,
except that no check is made using the value in
.BR FUTEX_CMP_REQUEUE
(see below), except that no check is made using the value in
.IR val3 .
(The argument
.I val3
@ -460,7 +447,15 @@ This operation was added as a replacement for the earlier
The difference is that the check of the value at
.I uaddr
can be used to ensure that requeueing happens only under certain
conditions.
conditions, which allows race conditions to be avoided in certain use cases.
.\" But, as Rich Flker points out, there remain valid use cases for
.\" FUTEX_REQUEUE, for example, when the calling thread is requeuing
.\" the target(s) to a lock that the calling thread owns
.\" From: Rich Felker <dalias@libc.org>
.\" Date: Wed, 29 Oct 2014 22:43:17 -0400
.\" To: Darren Hart <dvhart@infradead.org>
.\" CC: libc-alpha@sourceware.org, ...
.\" Subject: Re: Add futex wrapper to glibc?
Both operations can be used to avoid a "thundering herd" effect when
.B FUTEX_WAKE
is used and all of the waiters that are woken need to acquire