[cpp-threads] Yet another visibility question

[Nelson, Clark]

> If we wanted to allow this, I think we would
> 
> - Have a fetch_add_release happen-before (effectively 
> synchronize-with)
> the next fetch_add_release on the same variable.  The 
> cleanest way to do
> that seems to go back to the model in which any atomic store
> synchronizes-with an atomic load that reads that (or a later) value.
> Acquire and release would be special only in that they were
> inter-thread-ordered with respect to other operation in the 
> thread.  (We
> previously decided on the other approach here, but I think 
> the arguments
> were weak.  See the thread labelled "visibility question" at
> http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-Aug
> ust/thread
> .html)
> 
> - Have the fetch_add_release be inter-thread-ordered-before the
> dependent store to x.  Currently this is true for atomic x, so I think
> this wouldn't be a disaster.  It would prohibit some kinds of compiler
> analysis on the possible value of atomics, but we already do some of
> that.  It would introduce an asymmetry into the data race 
> definition, as
> required.
> 
> On the plus side, I currently think it's not that hard to update the
> wording to reflect this, and it seems to make it easier to express the
> per-variable TSO constraint that we decided we need.
> 
> Opinions?

I'm concerned about the fact that you're talking in terms of a specific
function (fetch_add_release) instead of a general operation. I suspect
that's just a shorthand, but I don't know how to generalize to what you
really mean. Do you? Or have you not yet had a chance to think about it
enough?

Clark