RE: [PATCH][RFC] Remove volatile from data members in libstdc++

["Boehm, Hans" <hans dot boehm at hp dot com>]

I think we are all in violent agreement that volatile isn't guaranteed
to solve the problem.

But I still claim it's closer than other viable mechanisms we currently
have.  Thus it's the best available stop-gap workaround until the
underlying issues get fixed.

The other alternatives that have been suggested are:

1) The atomicity.h functionality in libstdc++.

2) The __sync_ gcc intrinsics.

3) volatile assembly code.

I think neither (1) nor (2) really apply here.  They should be (and soon
will be, I hope) used for atomic read-modify-write operations.  But they
don't support plain atomic loads and stores.  For rope at least, it's
the reference count loads (for copy-avoidance) that are the issue.

(3) is probably correct, but I don't think it's practical to put
machine-specific in-line assembly code in such library code.

One could argue that the right solution is to add loads and stores to
(2).  But that quickly runs into another major weakness of the current
primitives: They don't allow the right kind of control over memory
ordering/visibility.  If you tried to follow the current design and
include a full memory fence everywhere, the resulting atomic loads would
be completely unusable, at least on machines like Pentium 4s that have
slow fences.

If you try to solve all these problems, you get roughly to where the
current C++ standard proposal for atomic operations
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2047.html)
currently is.  It seems to me that that's really the right place to
carry on this discussion.

Hans

> -----Original Message-----
> From: Ian Lance Taylor [mailto:iant@google.com] 
> Sent: Wednesday, July 12, 2006 6:15 PM
> To: Boehm, Hans
> Cc: Richard Guenther; Paolo Carlini; gcc-patches@gcc.gnu.org; 
> libstdc++@gcc.gnu.org
> Subject: Re: [PATCH][RFC] Remove volatile from data members 
> in libstdc++
> 
> "Boehm, Hans" <hans.boehm@hp.com> writes:
> 
> > a) Tell the compiler that asynchronous changes are 
> possible, and hence 
> > hopefully reduces the probability of performing 
> transformations that 
> > are unsafe in their presence, and
> 
> But, as I'm sure you know, volatile doesn't really tell the 
> compiler that.  Volatile tells the compiler that it needs to 
> access the data precisely as it is written.  In particular 
> volatile doesn't force the compiler to do anything 
> atomically, with the exception of assignments to variables of 
> type "volatile sig_atomic_t".  If you need atomic operations, 
> you need to tell the compiler that, e.g., by using the atomic 
> builtins which gcc now provides (following icc), or by using 
> volatile inline asm statements with memory clobbers.
> 
> > As far as (a) is concerned, I'm also worried about more complex 
> > compiler transformations.  For example, without the volatile 
> > declaration, in some circumstances it is acceptable for the 
> compiler 
> > to read the reference count more than once if it has to be spilled 
> > from a register.  Thus the same unmodified const local copy could 
> > appear to contain two different values in different places. 
>  I really 
> > don't want to have to reason about such things.
> 
> This is true.  But if you implement atomic operations, which 
> is really what you need, then this can't happen anyhow.
> 
> Ian
>