[cpp-threads] modes

[Doug Lea]

>>The minimal list seems to be along the lines of
>>  read-with-acquire
>>  write-with-release
>>  write-preserving-order
>>  CAS-with-acquire-release
>>  CAS-with-release
>>(plus the default ordinary-read and ordinary-write)
>>
>>We'd still need to spell out the details of exactly what acquire,
>>release, and write-ordering mean, especially wrt the highly
>>inconvenient sequence-point wording of the rest of the C++ spec.
> 
> 
> The good thing about acquire and release is that a write-with-release on a 
> memory location X happens-before a subsequent load-with-acquire on the same 
> memory location. :-)
> 
> But there are two problems with the above set.
> 
> The first problem is that it's missing unconstrained atomics. 

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.


> The second problem is that finer-grained constraints can eliminate some of 
> the barriers. 

I understand that. Can you tell me of a compelling use case where you
can show that it matters enough to be worthwhile supporting, especially
given the potential need to go from describing N^2 to (N+1)^2 possible
interactions across modes?

>>2. There's very little motivation to define CAS-with-acquire only.
> 
> 
> Isn't CAS with acquire on success the typical fast mutex lock path (and the 
> entire trylock implementation, for that matter)?

I do agree that this one is a close call. But to the best of my
knowledge, it is only faster when used for one  style of implementing
locks on one known platform.

Of course, the broader point here is where do you draw the line?
I didn't write my list insisting that these should be exactly what we
end up with, but only thinking that they were the ones we didn't need to
debate.

-Doug