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

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

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.

Hans

> -----Original Message-----
> From: Richard Guenther [mailto:rguenther@suse.de] 
> Sent: Saturday, July 15, 2006 2:22 AM
> To: Boehm, Hans
> Cc: Ian Lance Taylor; Paolo Carlini; gcc-patches@gcc.gnu.org; 
> libstdc++@gcc.gnu.org
> Subject: RE: [PATCH][RFC] Remove volatile from data members 
> in libstdc++
> 
> 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
>