This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: futex(3) man page, final draft for pre-release review
- From: "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>
- To: Davidlohr Bueso <dave at stgolabs dot net>
- Cc: mtk dot manpages at gmail dot com, Thomas Gleixner <tglx at linutronix dot de>, Darren Hart <dvhart at infradead dot org>, Torvald Riegel <triegel at redhat dot com>, lkml <linux-kernel at vger dot kernel dot org>, libc-alpha <libc-alpha at sourceware dot org>, linux-man <linux-man at vger dot kernel dot org>, Carlos O'Donell <carlos at redhat dot com>, Roland McGrath <roland at hack dot frob dot com>, Jakub Jelinek <jakub at redhat dot com>, Ingo Molnar <mingo at elte dot hu>, bill o gallmeister <bgallmeister at gmail dot com>, bert hubert <bert dot hubert at netherlabs dot nl>, Jan Kiszka <jan dot kiszka at siemens dot com>, Eric Dumazet <edumazet at google dot com>, Arnd Bergmann <arnd at arndb dot de>, Rusty Russell <rusty at rustcorp dot com dot au>, Heinrich Schuchardt <xypron dot glpk at gmx dot de>, Andy Lutomirski <luto at amacapital dot net>, Daniel Wagner <wagi at monom dot org>, Anton Blanchard <anton at samba dot org>, Steven Rostedt <rostedt at goodmis dot org>, Rich Felker <dalias at libc dot org>, Jonathan Wakely <jwakely at redhat dot com>, Mike Frysinger <vapier at gentoo dot org>, Peter Zijlstra <peterz at infradead dot org>
- Date: Wed, 16 Dec 2015 16:40:55 +0100
- Subject: Re: futex(3) man page, final draft for pre-release review
- Authentication-results: sourceware.org; auth=none
- References: <56701916 dot 4090203 at gmail dot com> <20151215224119 dot GA28877 at linux-uzut dot site>
Hi David,
On 12/15/2015 11:41 PM, Davidlohr Bueso wrote:
> On Tue, 15 Dec 2015, Michael Kerrisk (man-pages) wrote:
>
>> 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 one of the arguments of the
>> futex() call) as the expected value of the futex word. The load???
>> ing of the futex word's value, the comparison of that value with
>> the expected value, and the actual blocking will happen atomi???
>>
>> FIXME: for next line, it would be good to have an explanation of
>> "totally ordered" somewhere around here.
>>
>> cally and totally ordered with respect to concurrently executing
>> futex operations on the same futex word.
>
> So there are two things here regarding ordering. One is the most obvious
> which is ordered due to the taking/dropping the hb spinlock. Secondly, its
> the cases which Peter brought up a while ago that involves atomic futex ops
> futex_atomic_*(), which do not have clearly defined semantics, and you get
> inconsistencies with certain archs (tile being the worst iirc).
>
> But anyway, the important thing users need to know about is that the atomic
> futex operation must be totally ordered wrt any other user tasks that are trying
> to access that address. This is not necessarily the case for kernel ops. Peter
> illustrates this nicely with lock stealing example;
> (see https://lkml.org/lkml/2015/8/26/596).
Thanks. I reworded things here a little.
> Internally, I believe we decided that making it fully ordered (as opposed to
> making use of implicit barriers for ACQUIRE/RELEASE), so you'd endup having
> an MB ll/sc MB kind of setup.
>
> [...]
>
>> #include <stdio.h>
>> #include <errno.h>
>> #include <stdlib.h>
>> #include <unistd.h>
>> #include <sys/wait.h>
>> #include <sys/mman.h>
>> #include <sys/syscall.h>
>> #include <linux/futex.h>
>> #include <sys/time.h>
>>
>> #define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); \
>> } while (0)
>
> Nit, but for this we have err(3).
I don't much like them though (not in POSIX).
Thanks for the help David.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/