Messages in this thread | | | Date | Wed, 28 Aug 2013 10:19:37 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH RFC v2 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation |
| |
On Tue, Aug 27, 2013 at 06:21:29PM -0700, Paul E. McKenney wrote: > On Tue, Aug 27, 2013 at 03:53:10PM +0200, Peter Zijlstra wrote: > > On Tue, Aug 27, 2013 at 09:14:36AM -0400, Steven Rostedt wrote: > > > > > I just had this conversation with Paul McKenney. Should there be a > > > smp_mb_after_spin_unlock()? > > > > Depends on the benefits I suppose :-) Oleg and Linus did recently add > > smp_mb__before_spinlock(); > > > > > Although we blew it off as adding too many extensions to smp_mb(). But > > > it may be better than reimplementing something as complex as a lock. > > > > Locks should be as light weight as possible and never implement anything > > heavier than the ACQUISITION / RELEASE barriers if at all possible. We > > should certainly not re-implement spinlocks just to get full barriers > > out of them, that's crazy. > > An unlock followed by a lock needs to act like a full barrier, but there > is no requirement that a lock or unlock taken separately act like a > full barrier.
But that is already a property of the acquisition/release barrier.
| |