[cpp-threads] modes

[Doug Lea]

>>Sorry for not being clear. I meant that ordinary_read and
>>ordinary_write (or some better names) would be in the atomic classes.
>>Although even here we'd need to decide whether these
>>reads/writes must be bitwise-atomic. I think we once agrred they
>>should be.
> 
> 
> But once we have these, we can no longer claim sequential consistency.
> 

I think all is well. The basic model can talk only of modes.
Ordinary variables always only have one mode. Similarly
for locks and volatiles. But atomics can be used in any mode.
Which in effect means: A compliant program without atomics will be
"obviously" SC. Programs using atomics might or might not be
considered SC, depending on how they are used vs how they were
intended to be used.

> 
> 
> SPARC RMO and Alpha would still gain by eliding the leading #LoadLoad | 
> #StoreStore / mb, I believe.

Sparcs no longer come in RMO. Alphas soon won't come at all. Nothing
else I am aware of in the coming years would benefit.
There is lots of work in the hardware world that I'm not aware of,
but still.


> 
> The alternative, which I've been pursuing based on Alexander's 
> unidirectional constraint set, is to let implementations draw the line in 
> whatever manner they see fit.
> 

Remember that we need to balance all of: complexity of specification,
confidence in the correctness of the specification, burden on
conformance testing, programmer-usability, portability, and vendor
implementation effort. It's hard to argue that having 16 modes strikes
that balance.

-Doug