[cpp-threads] Yet another visibility question

[Boehm, Hans]

I think we're all talking about different aspects of the same problem.
The current proposal does not require TSO, even for a single location.
I'm convinced that without TSO on individual locations, weird things
happen.

I agree that in the specific case we were talking about, you can infer
that both fetch_add's happen earlier in some sense.  But they don't in
the happens-before sense.  And that's currently basically the only
terminology we have available in the proposal.

Doug also replied to me that he knows of no architecture on which this
kind of per-variable TSO would be an issue.  (I am not convinced that it
is currently officially required for X86.  But we've never let that stop
us in the past, and we can't.)  This is a much weaker property than real
TSO, in that we're only talking about a single location.

I'll think about how to phrase this for the proposal.

Hans

> I don't think I was depending on the order.  To recap, the example is
> 
> // x y z initially zero
> // thread 1
> x = 1; fetch_add_release( &z, +1 );
> // thread 2
> y = 1; fetch_add_release( &z, +1 );
> // thread 3
> if( load_acquire( &z ) == 2 ) assert( x == 1 && y == 1 );
> 
> For the if condition to be true, both releases must have 
> occurred and the new values of x and y should be visible.  
> There is no dependence on their order, only that they both 
> occurred.  Am I missing something?
> 
Not really.  But the whole notion of the fetch_add_releases "occurring
before" the load_acquire isn't something we can easily express.  We
clearly don't have a notion of time, since that would imply a total
ordering that we don't want here.

Hans