As commented on by Davidlohr Bueso:
This to me reads a bit too much into the kernel (fastpath,
refcnt, vmas). Why not just mention that it avoids overhead
in the kernel or something? I don't recall any manpage
mentioning such details, but I could be wrong.
Reported-by: Davidlohr Bueso <dave@stgolabs.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The kernel uses the following cast:
if (cmd == FUTEX_REQUEUE || cmd == FUTEX_CMP_REQUEUE ||
cmd == FUTEX_CMP_REQUEUE_PI || cmd == FUTEX_WAKE_OP)
val2 = (u32) (unsigned long) utime;
This ensures that always the least significant four bytes of the
pointer are used, both on ILP32 and LP64 systems.
On a big endian system a simple cast from 64 bit pointer to 32 bit
integer would return the most significant four bytes.
We have to make the reader of the man-page aware of the usage
of the least significant bytes.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Type u32 is not exposed to the user. Instead, refer to uint32_t,
which is defined in ISO/IEC 9899:1999.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Using the word "physical" address should make the text easier to
make.
Avoid negations like "may not be equal".
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Here is the result of a first pass over futex.2. I tried to
do nothing that is too controversial. I tried to apply the
terminology that at least Darren and I had in mind
consistently; but please check again.
The major changes are in how futexes are described in the
introductory parts of the page. I hope it's easier to understand
now. I've also tried to add some more precision to the the
description of the synchronization semantics (e.g., it makes a
difference whether we claim something is atomic (without further
qualification), or just atomic wrt. other futex operations).
In some cases, that adds some verbosity to the text -- but I
believe that this is worth the clarity and consistency in using
terms, for example.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The sentence is true for all man-pages. Remove it.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The abbreviation NPTL cannot be assumed to be common knowledge
of all readers of futex.7.
pthread.7 has details about the NPTL pthreads implementation.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
futex.7 is meant as overview of the usage of futexes. It should
point to the related man-pages.
pthreads are the main usage of futexes, refer to pthread.7.
Implementation of robust futexes requires knowledge of set_robust_list.2
and get_robust_list.2.
It is noworthy that a closing thread can wake up a futex. Hence mention
clone.2 and set_tid_address.2.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As reported by Rich Felker:
I see no code in the kernel whereby a "spurious wakeup",
or anything other than interruption by a signal handler
that's not SA_RESTART, can cause futex to fail with EINTR.
In general, overloading of EINTR and/or spurious EINTRs
from a syscall make it impossible to use that syscall for
implementing any function where EINTR is a mandatory
failure on interruption-by-signal, since there is no way
for userspace to distinguish whether the EINTR occurred
as a result of an interrupting signal or some other
reason. The kernel folks have gone to great lengths to fix
spurious EINTRs (see signal(7) for history), especially by
non-interrupting signal handlers, including in futex, and
allowing EINTR here would be contrary to that goal.
It's my belief that the "or a spurious wakeup" text should
simply be removed.
The reason I'm raising this topic is its relevance to a
thread on libc-alpha:
[RFC] mutex destruction (#13690): problem description and workarounds
The bug and mailing list discussions to which Rich refers are:
https://sourceware.org/bugzilla/show_bug.cgi?id=13690https://sourceware.org/ml/libc-alpha/2014-12/threads.html#0001
Torvald Riegel also reported the same issue, and Thomas Gleixner
noted that the "EINTR on spurious wakeup" behavior went away in
Linux 2.6.22. See the LKML thread, "futex() man page update help
request", Jan 2015:
http://thread.gmane.org/gmane.linux.kernel/1703405/focus=7734
Reported-by: Rich Felker <dalias@libc.org>
Reported-by: Torvald Riegel <triegel@redhat.com>
Reported-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Michael Kerrisk <mtknpages@gmail.com>
Michael Kerrisk