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

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

> 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 agree that a volatile cast for the read is just as good.  I think it
would be a step in the right direction to introduce a read/load inline
function into atomicity.h that for now just does the volatile cast and
dereference.  (A comment warning that currently platform-dependent
fences may be needed to enforce ordering would also be good.  I don't
think rope needs ordering guarantees, but the argument to that effect is
more subtle than it should be.) If we used that for unsynchronized
accesses to the reference count, then I think it would be OK to remove
the "volatile" from the declaration.



Hans