[cpp-threads] Visibility question

[Boehm, Hans]

Thinking about this example a bit more. I'm not 100% comfortable with
either answer.  With the synchronization edge, it's clear that ordered
atomic updates are not equivalent to the nonatomic version, even if they
operate on thread-private data.  That's ugly, though probably not a
showstopper for C++.  Without the synchronization edge, the outcome is
just plain weird.

Opinions?

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, August 01, 2006 3:28 PM
> To: C++ threads standardisation
> Subject: [cpp-threads] Visibility question
> 
> Clark brought up the following interesting question that I 
> couldn't immediately answer.  I think I now have the answer, 
> but I thought I would post it here to make sure we agree.
> 
> The question is whether "raw", i.e. unordered, atomic 
> operations should contribute to the happens-before relation.
> 
> As a particular example of what I mean, consider (x,y,z 
> atomic, w ordinary, everything initially zero):
> 
> Thread 1:
> w = 1;	// ordinary store
> y.fetch_add<ordered>(1);		// ordered atomic; orders
>                                   // everything within thread
> x.store<raw>(1);
> 
> Thread 2:
> r2 = x.load<raw>();
> z.fetch_add<ordered>(1);		// ordered atomic; orders
>          // everything within thread; different variable
> if (r2) r1 = w;	// ordinary load
> 
> Is there a data race on w?
> 
> Note that in all versions of the current draft proposal, the 
> statements within each thread are ordered by 
> inter-thread-ordered-before and hence happens-before.  
> (Unlike Java, the intra-thread sequencing order doesn't 
> automatically contribute to happens-before, but the ordered 
> atomics have that effect in this case.)
> 
> In the current draft proposals, there would be a synchronizes-with (or
> communicates-with) relationship introduced by both load-store pairs.
> Hence there would be no race.  The ordered fetch_adds and the 
> raw operations conspire to introduce a happens-before edge.
> 
> In the alternative formulation, the raw operations do not 
> introduce a synchronizes-with relationship, which means there 
> are no happens-before edges between threads, and there is a race.
> 
> My intuition is that the current formulation is right.  Opinions?
> 
> (With the formulation on the web, I think that eliminating 
> the happens-before edge between raw operations adds other 
> problems.  With the draft we're working on, I think we're 
> down to just problems like the one above.)
> 
> Hans
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>