Re: Control dependency between prior load in while condition and later store?

[Alan Stern <stern@rowland.harvard.edu>]

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