From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 20:13:14 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 75CE41065676 for ; Mon, 21 Apr 2008 20:13:14 +0000 (UTC) (envelope-from ravi.murty@intel.com) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mx1.freebsd.org (Postfix) with ESMTP id 550D58FC29 for ; Mon, 21 Apr 2008 20:13:14 +0000 (UTC) (envelope-from ravi.murty@intel.com) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP; 21 Apr 2008 13:11:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.25,691,1199692800"; d="scan'208";a="319613187" Received: from orsmsx335.amr.corp.intel.com (HELO orsmsx335.jf.intel.com) ([10.22.226.40]) by fmsmga002.fm.intel.com with ESMTP; 21 Apr 2008 13:11:35 -0700 Received: from orsmsx416.amr.corp.intel.com ([10.22.226.46]) by orsmsx335.jf.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Apr 2008 13:13:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Apr 2008 13:13:12 -0700 Message-ID: In-Reply-To: <480CF0F2.20609@elischer.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Do you really "sleep" when blocked on a mutex? Thread-Index: Acij6YnB27mady/SS/a4Y7CT4A4hxwAAgTYw References: <480CF0F2.20609@elischer.org> From: "Murty, Ravi" To: "Julian Elischer" X-OriginalArrivalTime: 21 Apr 2008 20:13:13.0370 (UTC) FILETIME=[208BC7A0:01C8A3EC] 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:13:14 -0000 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?) Ravi -----Original Message----- From: Julian Elischer [mailto:julian@elischer.org]=20 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, >=20 > =20 >=20 > 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. >=20 it really has two answers. 1/ sleep has a lot of historical baggage and is expected to work in=20 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=20 run queue, or not.. Having different higher layers allows us to do various sanity checks and to enforce the different behaviour. > =20 >=20 > 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? >=20 > =20 >=20 > Thanks >=20 > Ravi >=20 > =20 >=20 > _______________________________________________ > 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"