Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep
From: Peter Zijlstra
Date: Fri Jun 03 2016 - 08:28:14 EST
On Fri, Jun 03, 2016 at 02:23:10PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 03, 2016 at 05:08:27AM -0700, Paul E. McKenney wrote:
> > On Fri, Jun 03, 2016 at 11:38:34AM +0200, Peter Zijlstra wrote:
> > > On Fri, Jun 03, 2016 at 02:48:38PM +0530, Vineet Gupta wrote:
> > > > On Wednesday 25 May 2016 09:27 PM, Paul E. McKenney wrote:
> > > > > For your example, but keeping the compiler in check:
> > > > >
> > > > > if (READ_ONCE(a))
> > > > > WRITE_ONCE(b, 1);
> > > > > smp_rmb();
> > > > > WRITE_ONCE(c, 2);
> > >
> > > So I think it example is broken. The store to @c is not in fact
> > > dependent on the condition of @a.
> > At first glance, the compiler could pull the write to "c" above the
> > conditional, but the "memory" constraint in smp_rmb() prevents this.
> > From a hardware viewpoint, the write to "c" does depend on the "if",
> > as the conditional branch does precede that write in execution order.
> > But yes, this is using smp_rmb() in a very strange way, if that is
> > what you are getting at.
> Well, the CPU could decide that the store to C happens either way around
> the branch. I'm not sure I'd rely on CPUs not being _that_ clever.
> test %a, $0
> jnz 1f
> mov $1, %b
> 1: mov $2, %c
> Its not too much to ask the CPU to look ahead 2 instructions to figure
> out the store into c is going to happen unconditionally.
> I would really only rely on stores immediately dependent on the
Ah, interrupts could observe the difference, which is your execution
order constraint. So yes, maybe.
I'm still rather hesitant on this.