From 27dd3a6e790efa5f37609e54cdfecca8d03caedd Mon Sep 17 00:00:00 2001 From: Michael Kerrisk Date: Thu, 30 Jul 2015 09:17:53 +0200 Subject: [PATCH] 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 Date: Wed, 29 Oct 2014 22:43:17 -0400 To: Darren Hart Cc: GLIBC Devel , ... 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 Signed-off-by: Michael Kerrisk --- man2/futex.2 | 27 +++++++++++---------------- 1 file changed, 11 insertions(+), 16 deletions(-) diff --git a/man2/futex.2 b/man2/futex.2 index 4900765eb..367228b23 100644 --- a/man2/futex.2 +++ b/man2/futex.2 @@ -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 +.\" Date: Wed, 29 Oct 2014 22:43:17 -0400 +.\" To: Darren Hart +.\" 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