struct turnstile and sleep mutex

John Baldwin jhb at
Thu Oct 13 10:02:16 PDT 2005

On Thursday 13 October 2005 05:05 am, rookie wrote:
> Hi,
> This would be a silly e-mail but I've not found too much material about
> that. I was studing at struct turnstile code (kern/subr_turnstile.c,
> sys/turnstile.h) and there's something is not too clear for me. In
> particular why owner priority propagation is required in struct
> turnstile objects? What it does cause?

Let's say Thread A is a high priority thread and blocks on lock K.  The K lock 
is owned by Thread B.  Thread A now cannot run until Thread B runs and 
releases the lock.  If Thread B has a low priority, then it may take a while 
before it runs, and other threads with priorities less than A but higher than 
B will run before B and thus effectively starve A.  What priority propagation 
(AKA priority lending) does is lending A's priority to B until B releases K 
enabling A to run.

> Another question is about sleep mutex implementation; In the comments
> inside the code I've seen "turnstiles are used to implement not
> sleepable lock". So why sleep locks are sleeped through turnstiles?
> They might not use condition variables/sleepqueues?

sleepqueues don't do priority propagation.  sleep queues are generally used to 
wait for an async event that may or may not come, such as a top-half thread 
waiting in a driver for an interrupt to come in with data.  Mutex waits are 
not indeterminate, however, as we don't let threads wait on async events 
(sleep queues) while holding mutexes, thus mutex waits will eventually be 
terminated barring someone getting stuck in an infinite loop while holding a 
mutex.  For this reason, mutexes use a separate thread queue mechanism that 
does priority propagation.  Priority propogation doesn't make sense for sleep 
queues since you can't identify an owner to lend priority to when you block.  
The async even could be triggered from anywhere.

John Baldwin <jhb at>  <><
"Power Users Use the Power to Serve"  =

More information about the freebsd-smp mailing list