lkml.org 
[lkml]   [2018]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Control dependency between prior load in while condition and later store?
On Wed, 4 Apr 2018, Daniel Jordan wrote:

> A question for memory-barriers.txt aficionados.
>
> Is there a control dependency between the prior load of 'a' and the
> later store of 'c'?:
>
> while (READ_ONCE(a));
> WRITE_ONCE(c, 1);

I would say that yes, there is.

> I have my doubts because memory-barriers.txt doesn't talk much about
> loops and because of what that document says here:
>
> In addition, control dependencies apply only to the then-clause and
> else-clause of the if-statement in question. In particular, it does
> not necessarily apply to code following the if-statement:
>
> q = READ_ONCE(a);
> if (q) {
> WRITE_ONCE(b, 1);
> } else {
> WRITE_ONCE(b, 2);
> }
> WRITE_ONCE(c, 1); /* BUG: No ordering against the read from 'a'. */

This refers to situations where the two code paths meet up at the end
of the "if" statement. If they don't meet up (because one of the paths
branches away -- especially if it branches backward) then the
disclaimer doesn't apply, and everything following the "if" is
dependent.

The reason is because the compiler knows that code following the "if"
statement will be executed unconditionally if the paths meet up, so it
can move that code back before the "if" (provided nothing else prevents
such motion). But if the paths don't meet up, the compiler can't
perform the code motion -- if it did then the program might end up
executing something that should not have been executed!

> It's not obvious to me how the then-clause/else-clause idea maps onto
> loops, but if we think of the example at the top like this...
>
> while (1) {
> if (!READ_ONCE(a)) {
> WRITE_ONCE(c, 1);
> break;
> }
> }
>
> ...then the dependent store is within the then-clause. Viewed this way,
> it seems there would be a control dependency between a and c.
>
> Is that right?

Yes, except that a more accurate view of the object code would be
something like this:

Loop: r1 = READ_ONCE(a);
if (r1)
goto Loop;
else
; // Do nothing
WRITE_ONCE(c, 1);

Here you can see that one path branches backward, so everything
following the "if" is dependent on the READ_ONCE.

Alan

\
 
 \ /
  Last update: 2018-04-04 22:35    [W:0.116 / U:3.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site