Is MTX_CONTESTED evil?

Seigo Tanimura tanimura at tanimura.dyndns.org
Mon Mar 15 21:22:01 PST 2004


_mtx_unlock_sleep() currently wakes up only one thread being blocked,
and leaves MTX_CONTESTED on a mutex.  According to Solaris Internals,
that strategy adds an overhead to check for MTX_CONTESTED on a mutex,
even though it is not held by any thread.  The thread waken up cannot
grab the mutex immediately by _obtain_lock() and have to go through
_mtx_lock_sleep().  The penalty tends to be large for a mutex with a
high contention, and we have at least one of such a mutex - Giant.

What would it be like if we axed MTX_CONTEST and let
_mtx_unlock_sleep() wake up all of the blocked threads?

-- 
Seigo Tanimura <tanimura at tanimura.dyndns.org> <tanimura at FreeBSD.org>


More information about the freebsd-arch mailing list