[cpp-threads] modes, interlude

[Doug Lea]

Boehm, Hans wrote:
> Some higher level issues before we dive back into the details:
> 
> 1) I think the implicit assumption in this discussion has been
> that the simplest solution has been the one with the smallest
> number of primitives, where a primitive is a memory operation
> with an ordering constraint.  I'd actually like to see us
> minimize the number of ordering constraints, but implement
> each ordering constraint with every memory operation for which
> it makes any sense at all.  It seems to me that disallowing
> meaningful combinations actually adds complexity.  (I think the
> discussion sort of moved there anyway, but I wanted to make it
> explicit.)
> 

The main issue here is:

Programs using raw (or weirdly moded) loads and stores of atomics
would have races, and hence undefined semantics if we treated
those the same way as ordinary variables. So we can't treat
them as races in that sense.

But if we define their semantics, why don't we do so for
all programs, even those with races in ordinary variables?!

I gave a shot to only supporting a few modes for atomics that
I thought we wouldn't have much trouble spec'ing out.
But didn't see a good way to do it.

Do you see a way out of this?

-Doug