From: paulmck@linux.vnet.ibm.com (Paul E. McKenney)
To: linux-arm-kernel@lists.infradead.org
Subject: Writes, smp_wmb(), and transitivity?
Date: Tue, 16 Feb 2016 03:13:40 -0800 [thread overview]
Message-ID: <20160216111340.GS6719@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160216095319.GA14509@arm.com>
On Tue, Feb 16, 2016 at 09:53:20AM +0000, Will Deacon wrote:
> On Mon, Feb 15, 2016 at 12:35:12PM -0800, Paul E. McKenney wrote:
> > On Mon, Feb 15, 2016 at 06:58:32PM +0000, Will Deacon wrote:
> > > On Mon, Feb 15, 2016 at 09:58:25AM -0800, Paul E. McKenney wrote:
> > > > Some architectures provide local transitivity for a chain of threads doing
> > > > writes separated by smp_wmb(), as exemplified by the litmus tests below.
> > > > The pattern is that each thread writes to a its own variable, does an
> > > > smp_wmb(), then writes a different value to the next thread's variable.
> > > >
> > > > I don't know of a use of this, but if everyone supports it, it might
> > > > be good to mandate it. Status quo is that smp_wmb() is non-transitive,
> > > > so it currently isn't supported.
> > > >
> > > > Anyone know of any architectures that do -not- support this?
> > > >
> > > > Assuming all architectures -do- support this, any arguments -against-
> > > > officially supporting it in Linux?
> > > >
> > > > Thanx, Paul
> > > >
> > > > ------------------------------------------------------------------------
> > > >
> > > > Two threads:
> > > >
> > > > int a, b;
> > > >
> > > > void thread0(void)
> > > > {
> > > > WRITE_ONCE(a, 1);
> > > > smp_wmb();
> > > > WRITE_ONCE(b, 2);
> > > > }
> > > >
> > > > void thread1(void)
> > > > {
> > > > WRITE_ONCE(b, 1);
> > > > smp_wmb();
> > > > WRITE_ONCE(a, 2);
> > > > }
> > > >
> > > > /* After all threads have completed and the dust has settled... */
> > > >
> > > > BUG_ON(a == 1 && b == 1);
> > >
> > > My understanding is that this test, and the generalisation to n threads,
> > > is forbidden on ARM. However, the transitivity of DMB ST (used to
> > > construct smp_wmb()) has been the subject of long debates, because we
> > > allow the following test:
> > >
> > >
> > > P0:
> > > Wx = 1
> > >
> > > P1:
> > > Rx == 1
> > > DMB ST
> > > Wy = 1
> > >
> > > P2:
> > > Ry == 1
> > > <addr dep>
> > > Rx == 0
> > >
> > >
> > > so I'd be uneasy about saying "it's all transitive".
> >
> > Agreed! For one thing, doesn't DMB ST need writes on both sides?
>
> Yes, but it's a common trap that people fall into where they think the
> above is forbidden because the DMB ST in P1 should order P0's write
> before its own write of y.
True enough.
> > But that is one reason that I am only semi-enthusiastic about this.
> > The potentially locally transitive case is -very- restrictive, applying
> > only to situations where -all- accesses are writes.
>
> I think that we will confuse people more by trying to describe the
> restricted case where we provide order than if we blanket say that its
> not transitive. I know Linus prefers to be as strong as possible, but
> this doesn't look like a realistic programming paradigm and having a
> straightforward rule that "rmb and wmb are not transitive" is much
> easier for people to deal with in my opinion.
That is a good explanation of why I am only semi-enthusiastic about
this. ;-)
Thanx, Paul
next prev parent reply other threads:[~2016-02-16 11:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-15 17:58 Writes, smp_wmb(), and transitivity? Paul E. McKenney
2016-02-15 18:58 ` Will Deacon
2016-02-15 20:35 ` Paul E. McKenney
2016-02-16 9:53 ` Will Deacon
2016-02-16 11:13 ` Paul E. McKenney [this message]
2016-02-16 18:59 ` Linus Torvalds
2016-02-16 19:36 ` 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=20160216111340.GS6719@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).