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

[Richard Guenther <rguenther at suse dot de>]

On Fri, 14 Jul 2006, Boehm, Hans wrote:

> Richard -
> 
> I don't fully understand what you're saying here.
> 
> Clearly, according to language standards, ordinary loads do not
> guarantee atomicity.  A compiler that always load an int in two halves
> is clearly standard conforming, according to current standards.
> Hopefully you agree?
> 
> So are you arguing that gcc always guarantees this, and since the
> __sync_ primitives are gcc-specific anyway, there is no need to do
> anything more?

Yes.

> I have not seen any such guarantee in the gcc documentation.  I will
> grant you that in most cases the cheapest way to load an aligned int is
> to do so atomically.  But not always.  Consider the following, where
> both local and global are known not to be modified by this code:
> 
> 	local = global;
> 	global2 = ...local...;
> 	l1: <code that needs lots of registers, but doesn't need local,
> and doesn't call functions>
> 	global3 = ...local...;
> 
> It is likely that local will have to be spilled at l1.  It can either be
> spilled to a stack location and reloaded from the stack location, or we
> can skip the store, and just reload local from global.  I claim that the
> latter is usually cheaper if the global is directly addressable.  And it
> certainly makes the load from global look nonatomic.  And in ways that
> would have been disallowed if global were declared volatile.
> 
> I have no idea whether gcc currently does this (maybe not) or whether
> some future version of gcc might(I wouldn't bet against it).

Sure it will do it.  And it is fine - it is even fine to load from
the spill location non-atomically, as only the original global is
to be treated atomically.  Now, if this is wrong, then you are missing
proper memory barriers from the 'code that needs lots of registers'.

Your code needs to be safe against changes of the atomic value, i.e.
if you read the value "atomically" there is no guarantee about the value
not changing - usually you design your counters in a way that _if_ the
value reaches a magic one (like zero), _then_ and only _then_ the
value cannot change anymore.

Richard.

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