Do you really "sleep" when blocked on a mutex?
attilio at freebsd.org
Mon Apr 21 21:46:12 UTC 2008
2008/4/21, Murty, Ravi <ravi.murty at intel.com>:
> When a thread cannot get a mutex (default mutex) and needs to be
> blocked, is it really put to sleep? From looking at the code it appears
> that it is inhibited (TD_SET_LOCK) but isn't really put to sleep.
>From a scheduler perspective, sleeping and blocking are 2 different
events but from a low level look-through there is not much difference.
What happens is that the thread is maked as inhibited, moved into a
different queue than runqueue and switched out.
What really changes is upper level behaviour.
TD_SET_LOCK is used in conjuction with turnstiles which basically
operate priority propagation on the 'lock owner' and so the turnstile
becames the recipient for blocked thread (in other word, the turnstile
is the 'different queue than runqueue' where the thread lives).
TD_SET_SLEEP, on the other side, is used in conjuction with sleepqueue
which doesn't operate priority propagation to lock owner (as long as,
often, this owner is not present -- just think to wait channels). In
this case the recipient is the sleepqueue and there the thread lives.
On a low level the paradigm is similar when a thread blocks using the
turnstile or sleeps using the sleepqueue:
- the thread is running so it is nomore present on any runqueue
- the thread is marked as inhibited
- the relevant event is signalled (lock / sleep)
- the thread is assigned to the new recipient (turnstile / sleepqueue)
- the thread is switched out
Peace can only be achieved by understanding - A. Einstein
More information about the freebsd-hackers