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

[Richard Guenther <rguenther at suse dot de>]

On Mon, 17 Jul 2006, Boehm, Hans wrote:

> I'm not at all sure we're understanding each other correctly, here.
> 
> I'm saying that if I write, say:
> 
> unsigned global;
> 
> unsigned f(void)
> {
>   unsigned local = global;
>   unsigned i, sum = 0;
> 
>   for (i = 0; i < local; ++i) sum += i;
>   ...unrelated code that doesn't touch i, sum, local, or global ...
>   for (i = 0; i < local; ++i) sum -= i;
>   return sum;
> } 
> 
> then f may return a nonzero value since the second reference to local
> may involve an implicit reload of local from global, and hence may not
> get the same value as the first time around.  I claim that doesn't make
> the load from global look very atomic, though it perhaps fails in a way
> that different from what you might have expected.
> 
> This is certainly not something I know how to program around.  And I
> would like to have a way of guaranteeing that this doesn't happen.  I
> believe "volatile" does provide this guarantee.  It may be that gcc also
> provides it for nonvolatiles, but I don't see this written down
> anywhere.  It's certainly not guaranteed by any current language
> standards, or by currently proposed revisions.

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?

Richard.

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