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

[Boehm, Hans]

In my view, the main advantage of the C++ (non-)proposal would be that
it is cheaper to implement on most architectures, incl. X86, and covers
all non-esoteric cases (e.g. DCL, flags to terminate wait loops).  On
Pentium 4s, I think the performance difference is large for writes, and
zero for reads (admittedly the more important case).

The disadvantage over the Java approach is that you don't get sequential
consistency by declaring everything volatile, and there are a few cases
in which the stronger semantics matter, e.g. Dekker's algorithm.

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 1:12 PM
> To: C++ threads standardisation
> Subject: RE: [cpp-threads] RE: volatile, memory models, threads
> 
> 
> Doug wrote:
> > Herb Sutter wrote:
> > > 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)?
> > 
> > I don't think we've discussed this is a while, but last I recall,
> > C++ volatile would be slightly weaker than Java, in that it could
> > map to IA64 ld.acq/st.rel. Although on x86 and sparc would 
> probably be 
> > implemented the same as Java: Reorder constraints, plus a 
> StoreLoad on 
> > writes.
> 
> And for what examples does this cause issues/limitations? I 
> was curious about your statement that Java volatile could be 
> used in a case where the proposed C++ volatile couldn't, 
> which makes me wonder/concerned about whether we're closing 
> doors we shouldn't close.
> 
> So I'd like to understand this, and I'd appreciate it if you 
> or someone else could show a quick motivating example(s), how 
> the solution to the example different in the two volatile 
> models, and what (and how ugly) the workarounds in the C++ 
> volatile model would be. Thanks in advance!
> 
> Herb
> 
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>