Messages in this thread | | | Date | Tue, 27 Aug 2013 18:21:29 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH RFC v2 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation |
| |
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.
Thanx, Paul
| |