Date: Mon, 21 Apr 2008 13:33:25 -0700 From: Julian Elischer <julian@elischer.org> To: "Murty, Ravi" <ravi.murty@intel.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Do you really "sleep" when blocked on a mutex? Message-ID: <480CFA15.9050807@elischer.org> In-Reply-To: <AEBCFC23C0E40949B10BA2C224FC61B00704452C@orsmsx416.amr.corp.intel.com> References: <AEBCFC23C0E40949B10BA2C224FC61B00704441C@orsmsx416.amr.corp.intel.com> <480CF0F2.20609@elischer.org> <AEBCFC23C0E40949B10BA2C224FC61B00704452C@orsmsx416.amr.corp.intel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@elischer.org] > Sent: Monday, April 21, 2008 12:54 PM > To: Murty, Ravi > Cc: freebsd-hackers@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@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?480CFA15.9050807>