locking/mutexes: Document quick lock release when unlocking

When unlocking, we always want to reach the slowpath with the lock's counter indicating it is unlocked. -- as returned by the asm fastpath call or by explicitly setting it. While doing so, at least in theory, we can optimize and allow faster lock stealing. When unlocking, we always want to reach the slowpath with the lock's counter indicating it is unlocked. -- as returned by the asm fastpath call or by explicitly setting it. While doing so, at least in theory, we can optimize and allow faster lock stealing.

Davidlohr Bueso committed 12 years ago

Commit 42fa5661 parent 242489c1 file · +9 −2Browse files

Unified · Split

kernel/locking/mutex.c+9−2

@@ -684,9 +684,16 @@ __mutex_unlock_common_slowpath(struct mutex *lock, int nested) · 683 unmodified lines
684	684	unsigned long flags;
685	685
686	686	/*
687		− * some architectures leave the lock unlocked in the fastpath failure
	687	+ * As a performance measurement, release the lock before doing other
	688	+ * wakeup related duties to follow. This allows other tasks to acquire
	689	+ * the lock sooner, while still handling cleanups in past unlock calls.
	690	+ * This can be done as we do not enforce strict equivalence between the
	691	+ * mutex counter and wait_list.
	692	+ *
	693	+ *
	694	+ * Some architectures leave the lock unlocked in the fastpath failure
688	695	* case, others need to leave it locked. In the later case we have to
689		− * unlock it here
	696	+ * unlock it here - as the lock counter is currently 0 or negative.
690	697	*/
691	698	if (__mutex_slowpath_needs_to_unlock())
692	699	atomic_set(&lock->count, 1);