Re: atomic_ops(3) and sync

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Wed Jun 16 2010 at 12:30:18 +0200, Manuel Bouyer wrote:
> On Wed, Jun 16, 2010 at 12:21:23PM +0200, Manuel Bouyer wrote:
> > > This behaviour is documented in atomic_ops(3) (your email does not
> > > provide clear indication as to if you read that part of the manpage,
> > > so I'll just quote it here):
> > > 
> > >     Atomic operations are strongly ordered with respect to each other.
> > >     The global visibility of other loads and stores before and after an
> > >     atomic operation is undefined.  Applications that require synchro-
> > >     nization of loads and stores with respect to an atomic operation must
> > >     use memory barriers.  See membar_ops(3).
> > > 
> > > So if you want to impose ordering on other accesses with respect to the
> > > atomic op you need to manually add membars.  Atomic itself does not,
> > > and should not, guarantee it.
> > 
> > OK, thanks. I didn't spot this from the man page. I'm still in
> > a x86-centric world I guess ...

Speaking of that, there's a per-arch cpp macro __HAVE_ATOMIC_AS_MEMBAR,
which I've interpreted to mean "atomic operations provide full membar"
(but haven't found any documentation to confirm it).

> But it seems there's a problem with our membar_ops too:
> (gdb) disas membar_enter
> Dump of assembler code for function membar_sync:
> 0xffffffffc02b1b70 <membar_sync+0>:     jr      ra
> 0xffffffffc02b1b74 <membar_sync+4>:     nop
> 0xffffffffc02b1b78 <membar_sync+8>:     sync
> 0xffffffffc02b1b7c <membar_sync+12>:    nop
> 
> the assembler inserted a nop in the delay slot; I guess membar_ops.S
> needs ".set noreorder" at the top.

So membar comes out as nop?  Heh, that's a very high performance membar ;)