Re: atomics: document that linux expects certain atomic behaviour from unsigned long

[Nick Piggin <nickpiggin@yahoo.com.au>]

On Tuesday 06 January 2009 04:30:04 Paul E. McKenney wrote:
> On Tue, Jan 06, 2009 at 03:25:12AM +1100, Nick Piggin wrote:
> > On Tuesday 06 January 2009 03:05:01 Paul E. McKenney wrote:
> > > On Mon, Jan 05, 2009 at 11:00:24PM +1100, Nick Piggin wrote:
> > > > On Monday 05 January 2009 22:23:50 Alan Cox wrote:
> > > > > > Pretty much everywhere that uses RCU for example does so using
> > > > > > atomic pointer loads and stores. The nastiest issue IMO actually
> > > > > > is reloading the value through the pointer even if it isn't
> > > > > > explicitly dereferenced. RCU gets this right with ACCESS_ONCE.
> > > > > > Probably a lot of code using basic types does not. x86
> > > > > > atomic_read maybe should be using ACCESS_ONCE too...
> > > > >
> > > > > I'm pretty sure it should. gcc makes no guarantees about not being
> > > > > clever with accesses.
> > > >
> > > > Arguably it should. I don't know what the concurrent C standard looks
> > > > like, but prohibiting reloads of potentially concurrently modified
> > > > memory when there is no explicit pointer dereference is the natural
> > > > complement to prohibiting stores to potentially concurrently read
> > > > memory when there is no explicit store (which I think is begrudgingly
> > > > agreed to be a problem).
> > > >
> > > > http://lkml.org/lkml/2007/10/24/673
> > > >
> > > > I think I would like to see multiple reloads to local variables
> > > > prohibited, to avoid potential really subtle problems... But if
> > > > ACCESS_ONCE is here to stay, then I do think that atomic_read etc
> > > > should use it.
> > >
> > > The concurrency stuff in c++0x still permits the compiler to have its
> > > way with loads and stores to normal variables, but provides an "atomic"
> > > type that must be loaded and stored as specified in the program.
> >
> > So:
> > if (trylock())
> >   locked = 1;
> > ...
> > if (locked)
> >   *var = blah;
> > ...
> > if (locked)
> >   unlock();
> >
> > So the second part can still be transformed into a predicated calculation
> > of blah, then an unconditional store to *var?
>
> Assuming that "var" is an ordinary variable...
>
> If you are asking whether the compiler guys believe that they are within
> their rights to do a store to *var and then store the old value to *var
> if !locked, the unfortunate answer is "yes".  Hence ACCESS_ONCE().

Right. Part of the problem is that it might not be so clear. Each part of
the above sequence might be somewhat hidden by different call chains, gotos,
etc. *var = blah may not be that simple in form but actually be a call to
some helper function (which ends up being inlined, etc).

if (!trylock())
  return;

*var = blah;

unlock();

This is basically the same sequence, isn't it? var definitely doesn't need
to be atomic. It actually shouldn't have to be subject to any compiler
constraints within the critical section in order for the compiler to
generate an optimal critical section.


> > > The issue with ACCESS_ONCE() is that gcc doesn't do any optimizations
> > > on volatile accesses, even the obvious ones.  Speaking of which, the
> > > gcc guys kicked out my bug 33102, which was complaining about this
> > > situation.  :-/
> >
> > Hmm. It's still quite annoying even to have to switch everything to the
> > atomic type. I guarantee there will be bugs in Linux caused by the
> > compiler reloading pointers/longs/ints to access local variables...
>
> Another approach would be to change ACCESS_ONCE() to use the atomic
> types.  Then we have a bigger hammer with which to beat the gcc guys
> about optimizations.  We can hope, anyway...

Well... I'm less concerned about performance as correctness and difficulty
of programming this model.