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

[Boehm, Hans]

Dave -

I think the issue of volatile needs to be revisited once the memory
model and atomics library has settled down.  The Berlin meeting may be
the right time for that.

One possible outcome is that the semantics of volatile remains useless
for threads.  If you need a flag for inter-thread communication, you
write something like

atomic<bool> flag;

instead of

volatile bool flag;

It may be that atomic<T> would have an assignment operator that behaves
somewhat like a Java volatile assignment.  But I'm not sure whether
that's desirable.

There seem to be very mixed opinions within our group on the subject of
either redefining volatile or adding a different volatile-like type
qualifier.  My impression is that the C++ committee is actually more
favorably inclined towards that approach, but the detailed implications
haven't been considered.

If we can get reasonable syntax out of a library-based approach, I'm not
sure there's a strong argument for touching volatile.  (Divergence from
Java bothers me a bit, but this is in a fairly esoteric area, which we
can probably live with.  I do think we want to avoid making the teaching
of concurrent programming any harder than it inherently has to be.  And
designing fundamentally inconsistent concurrency facilities into
different languages without good reason is certainly one way to make it
harder.)

Hans

> -----Original Message-----
> From: David Abrahams [mailto:dave at boost-consulting.com] 
> Sent: Sunday, February 19, 2006 3:53 PM
> To: Andrei Alexandrescu; cpp-threads at decadentplace.org.uk; Boehm, Hans
> Subject: Re: volatile, memory models, threads
> 
> Andrei Alexandrescu <andrei at metalanguage.com> writes:
> 
> > Hey Dave,
> >
> >
> > Time hasn't allowed me to keep up with the process of standardizing 
> > threads. You may want to forward your question to 
> > cpp-threads at decadentplace.org.uk and/or to Hans Boehm at 
> hans.boehm at hp.com.
> 
> Done:
> 
> > Andrei
> >
> > David Abrahams wrote:
> >> Hi Andrei,
> >> N1777 says
> >>        "on some multiprocessors, there might not be any applicable
> >>         techniques short of heavy solutions such as the 
> insertion of
> >>         otherwise inaccessible locks. Thus, there may be types for
> >>         which the volatile qualifier either cannot be 
> supported on a
> >>         particular target platform, or would entail surprising time
> >>         and space overhead."
> >> Seems to me that adding volatile might therefore make some types 
> >> non-POD.  What guidance did your group get from the 
> committee on this 
> >> issue?
> 
> Any information will be much appreciated.
> 
> Thanks in advance,
> 
> --
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com
>