[cpp-threads] Yet another visibility question

[Boehm, Hans]

I had missed this question, and I'm still thinking about wording changes
for per-variable release store ordering.

For the example below, assuming an assertion fails:

(I'm assuming a version of assert that prints a message and continues;
otherwise no execution in which the assertion fails can not have x set
to 1 at all; thus such an execution could never be legal.)

- Accesses to y induce no synchronizes-with relationships at all, even
after the reformulation.

- The assignment to x is inter-thread-ordered after the corresponding
fetchadd_release.

- The assertions are inter-thread-ordered-before the corresponding
fetch_add_release.

- Each fetchadd_release precedes (but does not happen-before) the one
that reads its result.

Thus currently if the assertion fails in the thread A that sets y to
N-1, we have a cycle in the precedes relation, and this would be
disallowed.  Assuming B sets x to 1:

(A: assert) precedes (A: fetch_add) precedes (B: fetch_add) precedes (B:
x = 1) precedes (A: assert)

If the assertion fails in another thread, we simply get a longer chain
of fetchadds in the middle.

Thus I think this is already disallowed in the current version, though
the reasoning is a bit subtle.

Hans


> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk 
> [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf 
> Of Peter Dimov
> Sent: Tuesday, November 28, 2006 2:06 PM
> To: C++ threads standardisation
> Subject: Re: [cpp-threads] Yet another visibility question
> 
> Ping? :-)
> 
> Peter Dimov wrote:
> > Another question:
> > 
> > // x y initially zero
> > 
> > // threads 1 to N:
> > 
> > assert( x == 0 );
> > 
> > if( fetchadd_release( &y, 1 ) == N - 1 ) {
> >    x = 1;
> > }
> > 
> > Are the asserts guaranteed to pass? Informally, the causality 
> > constraint prevents the compiler or the hardware from speculatively 
> > executing the store before the fetchadd, even though there's no 
> > acquire label. But what does the MM say?
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>