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 ...
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.
--
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
NetBSD: 26 ans d'experience feront toujours la difference
--