From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 20:33:24 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C44F71065670 for ; Mon, 21 Apr 2008 20:33:24 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outL.internet-mail-service.net (outl.internet-mail-service.net [216.240.47.235]) by mx1.freebsd.org (Postfix) with ESMTP id B0D1E8FC1B for ; Mon, 21 Apr 2008 20:33:24 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 22 Apr 2008 03:23:31 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 09EEC2D6016; Mon, 21 Apr 2008 13:33:24 -0700 (PDT) Message-ID: <480CFA15.9050807@elischer.org> Date: Mon, 21 Apr 2008 13:33:25 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: "Murty, Ravi" References: <480CF0F2.20609@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Do you really "sleep" when blocked on a mutex? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2008 20:33:24 -0000 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"