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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
