[cpp-threads] Yet another visibility question

[Boehm, Hans]

Partially correcting myself:

I think the analysis below applies if x is an atomic, even if it is
accessed with unordered operations.  If x is an ordinary variable, there
is a race between the assert and the assignment to x.  And I think
that's what we want here.

Hans

> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk 
> [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf 
> Of Boehm, Hans
> Sent: Tuesday, November 28, 2006 5:55 PM
> To: C++ threads standardisation
> Subject: RE: [cpp-threads] Yet another visibility question
> 
> 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
> > 
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>