All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Penyaev <roman.penyaev@profitbricks.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	andrea.parri@amarulasolutions.com,
	Will Deacon <will.deacon@arm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Nick Piggin <npiggin@gmail.com>,
	David Howells <dhowells@redhat.com>,
	Jade Alglave <j.alglave@ucl.ac.uk>,
	Luc Maranget <luc.maranget@inria.fr>,
	Akira Yokosawa <akiyks@gmail.com>, Ingo Molnar <mingo@kernel.org>
Subject: Re: LKMM litmus test for Roman Penyaev's rcu-rr
Date: Wed, 6 Jun 2018 16:41:20 +0200	[thread overview]
Message-ID: <CAJrWOzB8hz2qzNJAWfNdW_U_ArHmvCpzZVJBebsfQ3=eEiSh7w@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1806060950050.1359-100000@iolanthe.rowland.org>

On Wed, Jun 6, 2018 at 3:54 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Wed, 6 Jun 2018, Roman Penyaev wrote:
>
>> > Preserving the order of volatile accesses isn't sufficient.  The
>> > compiler is still allowed to translate
>> >
>> >         r1 = READ_ONCE(x);
>> >         if (r1) {
>> >                 ...
>> >         }
>> >         WRITE_ONCE(y, r2);
>> >
>> > into something resembling
>> >
>> >         r1 = READ_ONCE(x);
>> >         WRITE_ONCE(y, r2);
>> >         if (r1) {
>> >                 ...
>> >         }
>>
>> Hi Alan,
>>
>> According to the standard C99 Annex C "the controlling expression of
>> a selection statement (if or switch)" are the sequence points, just
>> like a volatile access (READ_ONCE or WRITE_ONCE).
>>
>> "5.1.2.3 Program execution" states:
>> "At certain specified points in the execution sequence called sequence
>> points, all side effects of previous evaluations shall be complete
>> and no side effects of subsequent evaluations shall have taken place."
>>
>> So in the example we have 3 sequence points: "READ_ONCE", "if" and
>> "WRITE_ONCE", which it seems can't be reordered.  Am I mistaken
>> interpreting standard?  Could you please clarify.
>
> Well, for one thing, we're talking about C11, not C99.

C11 is a n1570, ISO/IEC 9899:2011 ? (according to wiki).  Found pdf on
the web contains similar lines, so should not be any differences for
that particular case.

> For another, as far as I understand it, the standard means the program
> should behave _as if_ the side effects are completed in the order
> stated.  It doesn't mean that the generated code has to behave that way
> literally.

Then I do not understand what are the differences between "side effects
are completed" and "code generated".  Abstract machine state should
provide some guarantees between sequence points, e.g.:

    foo();    /* function call */
    ------------|
    *a = 1;     |
    *b = 12;    | Compiler in his right to reorder.
    *c = 123;   |
    ------------|
    boo();    /* function call */

compiler in his right to reorder memory accesses between foo() and
boo() calls (foo and boo are sequence points, but memory accesses
are not), but:

   foo();    /* function call */
   *(volatile int *)a = 1;
   *(volatile int *)b = 12;
   *(volatile int *)c = 123;
   boo();    /* function call */

are all sequence points, so compiler can't reorder them.

Where am I mistaken?

> And in particular, the standard is referring to the
> behavior of a single thread, not the interaction between multiple
> concurrent threads.

Yes, that is clear: we are talking about code reordering in one
particular function in a single threaded environment.

--
Roman

  reply	other threads:[~2018-06-06 14:41 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-28 22:08 LKMM litmus test for Roman Penyaev's rcu-rr Paul E. McKenney
2018-05-29 18:35 ` Alan Stern
2018-05-29 18:35   ` Alan Stern
2018-05-29 19:03   ` Paul E. McKenney
2018-05-29 20:49     ` Alan Stern
2018-05-29 20:49       ` Alan Stern
2018-05-29 21:10       ` Linus Torvalds
2018-05-29 22:53         ` Paul E. McKenney
2018-05-30 14:46           ` Alan Stern
2018-05-30 14:46             ` Alan Stern
2018-05-30 14:29         ` Alan Stern
2018-05-30 14:29           ` Alan Stern
2018-05-30 14:59           ` Linus Torvalds
2018-05-30 18:10             ` Alan Stern
2018-05-30 18:38             ` Paul E. McKenney
2018-05-30 19:08               ` Alan Stern
2018-05-30 19:08                 ` Alan Stern
2018-05-30 19:45                 ` Paul E. McKenney
2018-05-30 19:45                   ` Paul E. McKenney
2018-05-30 19:45                   ` Paul E. McKenney
2018-05-30 20:28                   ` Alan Stern
2018-05-30 20:28                     ` Alan Stern
2018-05-30 21:49                     ` Paul E. McKenney
2018-05-30 22:01                 ` Linus Torvalds
2018-05-30 23:14                   ` Paul E. McKenney
2018-05-31 14:27                     ` Alan Stern
2018-05-31 14:27                       ` Alan Stern
2018-06-02 14:44                       ` Paul E. McKenney
2018-06-04 14:17                         ` Alan Stern
2018-06-04 14:17                           ` Alan Stern
2018-06-04 16:01                           ` Paul E. McKenney
2018-06-06  9:40                 ` Roman Penyaev
2018-06-06 13:54                   ` Alan Stern
2018-06-06 13:54                     ` Alan Stern
2018-06-06 14:41                     ` Roman Penyaev [this message]
2018-06-06 15:55                       ` Alan Stern
2018-06-06 15:55                         ` Alan Stern
2018-06-06 19:07                   ` Paul E. McKenney
2018-06-06 19:23                     ` Linus Torvalds
2018-06-07  9:43                       ` Paul E. McKenney
2018-06-07 14:57                         ` Alan Stern
2018-06-07 14:57                           ` Alan Stern
2018-06-07 15:40                           ` Linus Torvalds
2018-06-07 15:06                         ` Linus Torvalds
2018-06-07 19:57                           ` Paul E. McKenney

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='CAJrWOzB8hz2qzNJAWfNdW_U_ArHmvCpzZVJBebsfQ3=eEiSh7w@mail.gmail.com' \
    --to=roman.penyaev@profitbricks.com \
    --cc=akiyks@gmail.com \
    --cc=andrea.parri@amarulasolutions.com \
    --cc=boqun.feng@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=j.alglave@ucl.ac.uk \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luc.maranget@inria.fr \
    --cc=mingo@kernel.org \
    --cc=npiggin@gmail.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=stern@rowland.harvard.edu \
    --cc=torvalds@linux-foundation.org \
    --cc=will.deacon@arm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.