public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: mtk.manpages@gmail.com, Thomas Gleixner <tglx@linutronix.de>,
	Darren Hart <dvhart@infradead.org>,
	Torvald Riegel <triegel@redhat.com>,
	lkml <linux-kernel@vger.kernel.org>,
	libc-alpha <libc-alpha@sourceware.org>,
	linux-man <linux-man@vger.kernel.org>,
	"Carlos O'Donell" <carlos@redhat.com>,
	Roland McGrath <roland@hack.frob.com>,
	Jakub Jelinek <jakub@redhat.com>, Ingo Molnar <mingo@elte.hu>,
	bill o gallmeister <bgallmeister@gmail.com>,
	bert hubert <bert.hubert@netherlabs.nl>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Eric Dumazet <edumazet@google.com>, Arnd Bergmann <arnd@arndb.de>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Andy Lutomirski <luto@amacapital.net>,
	Daniel Wagner <wagi@monom.org>, Anton Blanchard <anton@samba.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Rich Felker <dalias@libc.org>,
	Jonathan Wakely <jwakely@redhat.com>,
	Mike Frysinger <vapier@gentoo.org>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: futex(3) man page, final draft for pre-release review
Date: Wed, 16 Dec 2015 16:40:55 +0100	[thread overview]
Message-ID: <56718607.2080600@gmail.com> (raw)
In-Reply-To: <20151215224119.GA28877@linux-uzut.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/

  reply	other threads:[~2015-12-16 15:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-15 13:43 futex(3) man page, final draft for pre-release review Michael Kerrisk (man-pages)
2015-12-15 15:34 ` Torvald Riegel
2015-12-15 16:02   ` Michael Kerrisk (man-pages)
2015-12-15 21:18 ` Darren Hart
2015-12-16 15:54   ` Michael Kerrisk (man-pages)
2015-12-18 11:11     ` Torvald Riegel
2015-12-18 15:34       ` Jonathan Wakely
2015-12-19  6:54       ` Michael Kerrisk (man-pages)
2015-12-18 11:21   ` Torvald Riegel
2015-12-19  6:56     ` Michael Kerrisk (man-pages)
2015-12-15 22:41 ` Davidlohr Bueso
2015-12-16 15:40   ` Michael Kerrisk (man-pages) [this message]
2015-12-18 12:26   ` Torvald Riegel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56718607.2080600@gmail.com \
    --to=mtk.manpages@gmail.com \
    --cc=anton@samba.org \
    --cc=arnd@arndb.de \
    --cc=bert.hubert@netherlabs.nl \
    --cc=bgallmeister@gmail.com \
    --cc=carlos@redhat.com \
    --cc=dalias@libc.org \
    --cc=dave@stgolabs.net \
    --cc=dvhart@infradead.org \
    --cc=edumazet@google.com \
    --cc=jakub@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=jwakely@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=roland@hack.frob.com \
    --cc=rostedt@goodmis.org \
    --cc=rusty@rustcorp.com.au \
    --cc=tglx@linutronix.de \
    --cc=triegel@redhat.com \
    --cc=vapier@gentoo.org \
    --cc=wagi@monom.org \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox