[cpp-threads] modes

[Peter Dimov]

Doug Lea wrote:
>> No, this is impossible to optimize in general.
>>
>> int f()
>> {
>>     Stuff * p = asp.read_acq();
>>
>>     if( p != 0 )
>>     {
>>         return p->y;
>>     }
>>     else
>>     {
>>         return 0;
>>     }
>> }
>>
>> The compiler has no idea whether the reads and writes in the caller
>> of f() can safely be hoisted across the explicit acquire.
>
> Not usually a problem if you do inlining, dynamic compilation, and/or
> interprocedural dataflow. And if you don't, then inability
> to remove barrier is only an incremental cost over other
> call overheads.

It might be possible to optimize if there is another acquire in close 
proximity after the read. If everything between these two points is 
dependent, all is well.

Otherwise I don't see how the unbounded sequence of accesses following the 
read can be proven to be dependent or reorder-safe.

Anyway, regardless of what is specified, what will actually happen in 
practice (IMO) is this:

- programmers will not use an acquire barrier for dependent reads because it 
works on everything except Alpha;

- the implementation of read_none for Alpha (assuming the Alpha survives for 
so long) will just insert the #loadload to keep the code from breaking.