public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely@redhat.com>
To: Torvald Riegel <triegel@redhat.com>
Cc: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>,
	Darren Hart <dvhart@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	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>,
	Davidlohr Bueso <dave@stgolabs.net>,
	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>, Mike Frysinger <vapier@gentoo.org>
Subject: Re: futex(3) man page, final draft for pre-release review
Date: Fri, 18 Dec 2015 15:34:02 +0000	[thread overview]
Message-ID: <20151218153402.GV5356@redhat.com> (raw)
In-Reply-To: <1450437061.26597.45.camel@localhost.localdomain>

On 18/12/15 12:11 +0100, Torvald Riegel wrote:
>On Wed, 2015-12-16 at 16:54 +0100, Michael Kerrisk (man-pages) wrote:
>> Hello Darren,
>>
>> On 12/15/2015 10:18 PM, Darren Hart wrote:
>> > On Tue, Dec 15, 2015 at 02:43:50PM +0100, 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
>> >
>> > Totally ordered with respect futex operations refers to semantics of the
>> > ACQUIRE/RELEASE operations and how they impact ordering of memory reads and
>> > writes. The kernel futex operations are protected by spinlocks, which ensure
>> > that that all operations are serialized with respect to one another.
>> >
>> > This is a lot to attempt to define in this document. Perhaps a reference to
>> > linux/Documentation/memory-barriers.txt as a footnote would be sufficient? Or
>> > perhaps for this manual, "serialized" would be sufficient, with a footnote
>> > regarding "totally ordered" and a pointer to the memory-barrier documentation?
>>
>> I think I'll just settle for writing serialized in the man page, and be
>> done with it :-).
>
>I'd prefer if you'd not just use "serialized" :)  Eventually, I'd prefer
>if we can explain the semantics for the user in terms of the terminology
>and semantics of the memory model of the programming language that users
>will likely use to call futex ops (ie, C11 / C++11).

FWIW a couple of uses of "serialized" were replaced in the C++11 final
draft due to comments pointing out that term is not defined in the
standard, see http://wg21.link/lwg1494 and http://wg21.link/lwg1504

That's not quite the same, because an ISO standard is supposed to
define all terms it uses, even for something like "serialized" where
the meaning is commonly understood by those in the field.

But I do like Torvald's suggestion to describe the semantics in
similar terms to C11, because that's the user-space model that
non-kernel folks (like me) are more likely to be familiar with.

Overall I like the new page a lot, I found it clear and readable. Nice
work.


  reply	other threads:[~2015-12-18 15:38 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 [this message]
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)
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=20151218153402.GV5356@redhat.com \
    --to=jwakely@redhat.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=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=mtk.manpages@gmail.com \
    --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