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

That's actually what I was trying to get to.

If I look at vm_daemon(), it checks to see if every thread of the
process is running, on the runq or sleeping. If any threads fails the
condition - and I can think of the case where a thread is blocked
waiting for a lock - it is not a target to be swapped out. I guess this
means that if a thread is holding a lock, it can be swapped out. How
does this guarantee that the thread is not holding a kernel lock? Why
don't they allow threads waiting for a lock (blocked threads/processes)
to be swapped out?

Related question: how can a process/thread running on a CPU be swapped
out, do they suspend the threads before they pull out memory from
underneath them?

Thanks
Ravi


-----Original Message-----
From: Julian Elischer [mailto:julian@xxxxxxxxxxxx]
Sent: Monday, April 21, 2008 1:33 PM
To: Murty, Ravi
Cc: freebsd-hackers@xxxxxxxxxxx
Subject: Re: Do you really "sleep" when blocked on a mutex?

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@xxxxxxxxxxxx]
Sent: Monday, April 21, 2008 12:54 PM
To: Murty, Ravi
Cc: freebsd-hackers@xxxxxxxxxxx
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@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to
"freebsd-hackers-unsubscribe@xxxxxxxxxxx"

_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Locking etc. (Long, boring, redundant, newbie questions)
    ... What is really meant is that depending on the type of mutex a thread is trying to acquire, the thread will either spin or it will sleep waiting for the lock to become available. ...
    (freebsd-hackers)
  • Locking etc. (Long, boring, redundant, newbie questions)
    ... sleep waiting for the lock to become available. ... mutex protects. ... if we spin for so long ...
    (freebsd-hackers)
  • Re: Recursive mutex that can be waited upon (pthread)
    ... on an object, you are releasing the lock to the object, hence of course ... If Thread 1 kept the lock when going to sleep, ... I'm trying to avoid spin-locks basically. ... *mutex* threads use to synchronize access to that data. ...
    (comp.programming.threads)
  • Re: witness oddity
    ... >> back in during which time your mutex will continue to be held. ... > being in a deadlock with the vm map lock. ... or sleep?) ... copyouttakes a page fault it can sleep, so holding a mutex across copy* ...
    (freebsd-current)
  • Re: Do you really "sleep" when blocked on a mutex?
    ... When a thread cannot get a mutex and needs to be ... that it is inhibited but isn't really put to sleep. ... the nesting of held resources will be safe, ... between setrunnableand setrunqueue() - this one simply finds a slot ...
    (freebsd-hackers)