> Ah, but this is something different. Both lock/unlock are full barriers,
> but they protect only one direction. A memory op must not leak out of the
> critical section, but it may leak in.
>
> A = B; // 1
> lock(); // 2
> C = D; // 3
>
> this can be re-ordered to
>
> lock(); // 2
> C = D; // 3
> A = B; // 1
>
> but 2 and 3 must not be re-ordered.
>
> To be sure, I contacted Paul E. McKenney privately, and his reply is
>
> > No. See for example IA64 in file include/asm-ia64/spinlock.h,
> > line 34 for spin_lock() and line 92 for spin_unlock(). The
> > spin_lock() case uses a ,acq completer, which will allow preceding
> > reads to be reordered into the critical section. The spin_unlock()
> > uses the ,rel completer, which will allow subsequent writes to be
> > reordered into the critical section. The locking primitives are
> > guaranteed to keep accesses bound within the critical section, but
> > are free to let outside accesses be reordered into the critical
> > section.
> >
> > Download the Itanium Volume 2 manual:
> >
> >
http://developer.intel.com/design/itanium/manuals/245318.htm
> >
> > Table 2.3 on page 2:489 (physical page 509) shows an example of how
> > the rel and acq completers work.
