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

[Boehm, Hans]

Herb -

I think the discussion has always been based on the assumptions that

a) There will be some sort of atomics library, or possibly language
support.  You need this to get access to primitives like fetch-and-add
or compare-and-swap.  This is mostly experts-only stuff.  But it is
currently reimplemented in so many places, and often not very well, that
I think it's important to have it.  (And there are a few places where
it's directly useful for relatively simple things.  I don't know how
often I've heard the claim that if you're gathering some sort of event
counts in multiple threads, you can just increment a global without
locking, since it won't be off by too much.  That's dangerous, and often
wrong.  Fetch-and-add fixes it more cheaply than locks.)  This would
very roughly be the C++ analog of JSR166 java.util.concurrent.atomic.
My assumption has been that this would basically let you do anything,
though perhaps with suboptimal syntax.

b) There may or may not be a type qualifier to support simple use of
atomics.  This would be sufficient for double-checked-locking and
similar idioms, which seem moderately common in end-user code.  (They
might become more common when they actually become correct.)  I don't
see how to make this the only atomics facility.  You do need library
routines (or new syntax) for things like fetch-and-add.  Once you have
those, there's nothing to prevent additional library routines that
enforce stronger ordering than what the type qualifier normally gives
you.

My inclination is to work on (a) first, and then see if we really need
(b), especially since (b) has generated lots of opposition in the past,
and there seems to be serious questions about its feasibility.

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: Thursday, March 02, 2006 7:49 AM
> To: C++ threads standardisation
> Subject: RE: [cpp-threads] RE: volatile, memory models, threads
> 
> Hans wrote:
> > 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.
> 
> Thanks. However, C++ is a systems programming language, and 
> it has to be possible to do the latter too.
> 
> One data point that comes to mind is that volatile data should be rare
> -- this is stuff for rocket scientists only -- and that 
> argues for not worrying as much about getting exactly optimal 
> performance. But on the other hand, when those rocket 
> scientists do this stuff, it's because they want performance.
> 
> So here's what I would suggest considering:
> 
>   - If the performance difference is large enough on some/all 
> architectures so as to provide a reason not to use the 
> feature, perhaps that is sufficient reason to consider 
> surfacing two abstractions, one with most of the power and 
> all the speed, and the other with all the power and perhaps 
> less speed on some systems.
> 
>   - Otherwise, surface one abstraction -- the one with all 
> the power (SC).
> 
> Can you explain what you mean by this being a "non"-proposal 
> -- is it that just this option isn't being proposed, or that 
> there is no proposal along the lines of Java "volatile" of 
> any kind? I had understood providing such an abstraction to 
> be a key part of the memory model.
> 
> Herb
> 
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>