Re: [PATCHv5 2/2] memory barrier: adding smp_mb__after_lock

Mathieu Desnoyers
2009-07-07T19:46:04Z

* Peter Zijlstra (a.p.zijlstra@chello.nl) wrote:
> On Tue, 2009-07-07 at 17:44 +0200, Oleg Nesterov wrote:
> > On 07/07, Mathieu Desnoyers wrote:
> > >
> > > Actually, thinking about it more, to appropriately support x86, as well
> > > as powerpc, arm and mips, we would need something like:
> > >
> > > read_lock_smp_mb()
> > >
> > > Which would be a read_lock with an included memory barrier.
> >
> > Then we need read_lock_irq_smp_mb, read_lock_irqsave__smp_mb, write_lock_xxx,
> > otherwise it is not clear why only read_lock() has _smp_mb() version.
> >
> > The same for spin_lock_xxx...
>
> At which time the smp_mb__{before,after}_{un,}lock become attractive
> again.
>

Then having a new __read_lock() (without acquire semantic) which would
be required to be followed by a smp__mb_after_lock() would make sense. I
think this would fit all of x86, powerpc, arm, mips without having to
create tons of new primitives. Only "simpler" ones that clearly separate
locking from memory barriers.

Mathieu

--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68