[cpp-threads] RE: volatile, memory models, threads

[Boehm, Hans]

I'm not sure that we really have such a proposal on the table anymore,
though I'd personally be happy to see it resurrected.  It has generated
lots of complaints along the lines that we would be changing the meaning
of volatile to something that is often more heavyweight than needed.

I mostly agree with Doug's recollection of the last proposal along these
lines.  It was very similar to the Java 5 use, except that references to
volatile variables would not be totally ordered.  In particular, stores
to a volatile would have release semantics (like Java), loads would have
acquire semantics (like Java), but (unlike Java) a volatile store
followed by a volatile load could be reordered.  I believe that (unlike
Java and Doug's recollection) there would be no fences required on X86,
and thus presumably SPARC TSO.

My assumption would be that atomicity is guaranteed only for individual
scalar accesses, and we can argue about whether it should apply for all
scalar types.  (long long and long double might be controversial.)

I'm still not quite sure how important this is, aside from consistency
across languages, and possibly implications for C.  We should probably
leave the latter to the C committee.

If the only real difference is that if I want to do double-checked
locking in Java, I write

volatile bool x_initialized;

but I have to write

atomic<bool> x_initialized;

in C++, I guess I could live with that.  But that would have to rely on
some moderately weird operator overloading.  And I haven't thought
through the implications of that.  Nor am I convinced that I'm capable
of thinking through all the implications of that.  These things often
seem to come with subtle gotchas.

Hans


> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk 
> [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf 
> Of Herb Sutter
> Sent: Wednesday, March 01, 2006 12:44 PM
> To: C++ threads standardisation
> Subject: RE: [cpp-threads] RE: volatile, memory models, threads
> 
> 
> 
> Doug wrote:
> > reading Bart Smaalders's ACM queue article
> > http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=366
> > where on the last page, he recommends using plain 
> concurrent reads on 
> > scalars rather than RWLocks or regular locks. In Java, this is fine
> if
> > such variables are declared "volatile". The way we are heading here,
> in
> > C/C++, it is likely to be OK only if an atomic type, which 
> will entail 
> > additional work and understanding that fewer programmers will get
> right.
> 
> As someone who hasn't closely followed all the details of the 
> various proposals and alternatives: Could you summarise the 
> difference between Java 5 volatile and the current proposal 
> for C++ volatile (assuming we do reuse that qualifier which 
> seems like a good idea)?
> 
> Herb
> 
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>