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

[Boehm, Hans]

> From: David Abrahams [mailto:dave at boost-consulting.com] 
> 
> Nick Maclaren <nmm1 at cus.cam.ac.uk> writes:
> 
> > "Boehm, Hans" <hans.boehm at hp.com> wrote:
> >>
> >> 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.
> >
> > That seems to summarise the state nicely!
> 
> Which of the two approaches above is indicated by "that 
> approach" is ambiguous, so I'm a bit more confused than youare.
Sorry about that.  My impression is that the C++ committee is more
favorably inclined towards adding some sort of volatile-like qualifier,
as opposed to a library-only approach, and is probably relatively open
towards changing the meaning of "volatile".  Others favor a
(syntactically) library-only solution.

Re: alignment and casting

This clearly needs to be though through carefully.  I think that with
the atomic<int>-style library solution, we don't have a problem.

At the other extreme of redefining volatile, I'm not sure how big the
problem is either.  All standard modern architectures seem to
sufficiently align small scalars that can be atomically loaded or
stored.  Usually not doing so involves as substantial performance hit.
(An M68K probably doesn't.  But with some work you could deal with that
on uniprocessors.  And I'm not sure that M68K multiprocessors matter
anymore.)

I know of no architecture that requires a lock to be associated with an
atomically accessed location just to get memory ordering.  (In a few
cases, it may be convenient to access another memory location, but AFAIK
that can be on your own stack.)  If you need to implement something like
fetch-and-add on an architecture that provides no atomic memory updates,
I think you would do it with a hash table of locks off to the side.  And
you would probably do this sort of thing only for atomic<T> objects, not
volatiles.  (The atomic_ops C package currently does this.  It probably
doesn't scale tremendously well, but I doubt that this will be necessary
on many machines in 2009.)

Hans