[cpp-threads] Yet another visibility question

[Hans Boehm]

In the current proposal (N2052), the assert is not guaranteed to succeed,
except in the fetch_add_ordered case.  A synchronizes with, and hence
happens before, B only of B is an acqire operation that reads the value
written by release operation A.

If you used r1 = load_acquire(y) in thread 2, the assert would always
succeed.

I'm OK with that behavior.

There's a difference from Java here, in that Java introduces
synchronizes-with relationships from earlier writes to later reads.  That
makes sense for the current Java spec only because operations on volatiles
are totally ordered.  There are on-going off-line discussions about
whether that's completely implementable on some common architectures.
This will no doubt be a topic of discussion at the Portland meeting a week
from today.

Hans

On Sun, 8 Oct 2006, Peter Dimov wrote:

> Consider:
>
> // initial values 0
>
> // thread 1
>
> x = 1; // ordinary store
> store_release( y, 1 );
>
> // thread 2
>
> r1 = load_raw( y ); // assume this reads 1
> store_release( y, r1+1 ); // ... and this stores 2
>
> // thread 3
>
> r2 = load_acquire( y ); // assume this reads 2
>
> if( r2 == 2 )
> {
>     assert( x == 1 ); // ordinary load
> }
>
> Will the assert pass? Is there a data race on x? What if thread 2's load had
> acquire semantics?
>
> Thread 2 can be rephrased as performing
>
> fetchadd_release( y, 1 );
>
> and
>
> fetchadd_ordered( y, 1 );
>
> respectively. Is this an equivalent transformation (from visibility
> standpoint, atomicity does not concern us for the moment)?
>
>
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>