Do you really "sleep" when blocked on a mutex?

[Julian Elischer]

Murty, Ravi wrote:
> Fundamentally it seems that they both come down to inhibiting the thread
> and putting them on some queue before calling mi_switch(). But when a
> thread is woken up from a sleep, setrunnable is called and it checks to
> see if the process is swapped out. No such check is made when a thread
> is waiting for a lock (I'm wondering if this is related to how long they
> block before becoming runnable which might cause a swapout in one case
> and no swapout in the other case?)

blocking processes/threads are not eligible to be swapped out.

> 
> Ravi
> 
> 
> -----Original Message-----
> From: Julian Elischer [mailto:julian at elischer.org] 
> Sent: Monday, April 21, 2008 12:54 PM
> To: Murty, Ravi
> Cc: freebsd-hackers at freebsd.org
> Subject: Re: Do you really "sleep" when blocked on a mutex?
> 
> Murty, Ravi wrote:
>> Hello,
>>
>>  
>>
>> 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.
>>
> it really has two answers.
> 
> 1/ sleep has a lot of historical baggage and is expected to work in 
> certain ways.
> 
> 2/ there is a semantic difference between a sleep
> (which may sleep for an unbounded time) and being descheduled for
> a blocking lock, (Which is supposed to have a guaranteed "shortness"
> of duration.
> 
> Because sleeps 'may never return' (in the short term) there is a
> limit of what you may hold when sleeping. In blocking locks
> you may hold other resources, with the expectation that the
> other threads will be following the correct locking order and that
> the nesting of held resources will be safe, because you will
> only be blocked for a moment.
> 
> The lowest leven code is the same of course.. things are put on the 
> run queue, or not.. Having different higher layers allows us to do
> various sanity checks and to enforce the different behaviour.
> 
> 
>>  
>>
>> 1.	Why isn't it put to sleep - why can't it be treated the same?
>> 2.	The eventual question I am trying to answer is the difference
>> between setrunnable() and setrunqueue() - this one simply finds a slot
>> in the ksegrp and a runq to add the KSE/td. But setrunnable() also
>> checks to see if the process is in memory (PS_INMEM) before calling
>> sched_wakeup which eventually calls setrunqueue()? Why doesn't
>> setrunqueue have to worry about the possibility that the process may
>> have been swapped out while it was waiting to become runnable?
>>
>>  
>>
>> Thanks
>>
>> Ravi
>>
>>  
>>
>> _______________________________________________
>> freebsd-hackers at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to
> "freebsd-hackers-unsubscribe at freebsd.org"