Messages in this thread | | | Subject | Re: [PATCH v2 2/5] mutex: Modify the way optimistic spinners are queued | From | Jason Low <> | Date | Tue, 28 Jan 2014 14:10:41 -0800 |
| |
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
| |