On Tue, 2014-01-28 at 12:23 -0800, Paul E. McKenney wrote: > On Tue, Jan 28, 2014 at 11:13:13AM -0800, Jason Low wrote: > > /* > > * The cpu_relax() call is a compiler barrier which forces > > @@ -514,6 +511,7 @@ __mutex_lock_common(struct mutex *lock, long state, > > unsigned int subclass, > > */ > > arch_mutex_cpu_relax(); > > } > > + mspin_unlock(MLOCK(lock), &node); > > slowpath: > > Are there any remaining goto statements to slowpath? If so, they need > to release the lock. If not, this label should be removed.
Yes, if the mutex_can_spin_on_owner() returns false, then the thread goes to directly slowpath, bypassing the optimistic spinning loop. In that case, the thread avoids acquiring the MCS lock, and doesn't unlock the MCS lock. Thanks, Jason -- 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/
