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

[Richard Guenther <rguenther at suse dot de>]

On Tue, 18 Jul 2006, Boehm, Hans wrote:

> > From: Richard Guenther [mailto:rguenther@suse.de] 
> > 
> > I believe gcc at the moment won't do it, but of course from 
> > the standards point of view it is permittet to treat local 
> > just like global inside the function.  And indeed volatile 
> > guarantees you a single access of global here - though it is 
> > sufficient to make the access volatile and not the data, like in
> > 
> >   unsigned local = *(volatile unsigned *)&global;
> > 
> > Of course the above example has nothing in common with say, 
> > the situation in ext/rope.  Or am I missing something?
> > 
> I'm not sure.  The problem is that without the volatile declaration, the
> compiler is allowed to assume that the reference count in rope, for
> example, does not change unless it is assigned to by that thread.  We're
> violating this assumption.  I'm not sure whether that assumption matters
> to anything that gcc does with the rope implementation, but I'm also not
> sure it doesn't.

I'm sure it doesn't.  As long as you use proper atomic increment/decrement
operations (proper as in let the compiler know the value is clobbered
and let the CPU carry out the operation atomically), no spilling or
caching or whatever else optimization can violate the invariants you
set for reference counting, which are (assuming zero is the unused case)

 - if the value (somehow) reads non-zero, any other means of reading
   the value will produce non-zero unless this thread decrements the
   value
 - if the value (somehow) reads zero, this thread had better just
   decremented the value, and any other further means of reading the
   value will produce zero, too.

you don't need volatile to ensure proper atomic counter behavior, you
don't need an "atomic read" thing, you only need atomic 
increment/decrement.

Richard.

--
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs