Date: Tue, 22 Apr 2008 02:03:27 +0200 From: "Attilio Rao" <attilio@freebsd.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: <3bbf2fe10804211703h6eebbde2q2054a30df1e0164b@mail.gmail.com> In-Reply-To: <AEBCFC23C0E40949B10BA2C224FC61B00704441C@orsmsx416.amr.corp.intel.com> References: <AEBCFC23C0E40949B10BA2C224FC61B00704441C@orsmsx416.amr.corp.intel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2008/4/21, Murty, Ravi <ravi.murty@intel.com>: > 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. > > > > 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? I just forgot to answer this: on 6.x serie (note that setrunqueue() shouldn't be available on 7.x and above), setrunqueue() is just used as backend for setrunnable(). Usually, setrunqueue() was used in places where the state of the thread was alredy assumed and no further check were needed. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10804211703h6eebbde2q2054a30df1e0164b>