From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 19:01:31 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 964DB106566C for ; Mon, 21 Apr 2008 19:01:31 +0000 (UTC) (envelope-from ravi.murty@intel.com) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mx1.freebsd.org (Postfix) with ESMTP id 75A868FC1F for ; Mon, 21 Apr 2008 19:01:31 +0000 (UTC) (envelope-from ravi.murty@intel.com) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 21 Apr 2008 11:59:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.25,691,1199692800"; d="scan'208,217";a="272961270" Received: from orsmsx334.amr.corp.intel.com (HELO orsmsx334.jf.intel.com) ([10.22.226.45]) by orsmga002.jf.intel.com with ESMTP; 21 Apr 2008 12:01:25 -0700 Received: from orsmsx416.amr.corp.intel.com ([10.22.226.46]) by orsmsx334.jf.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Apr 2008 12:01:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Apr 2008 12:01:29 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Do you really "sleep" when blocked on a mutex? Thread-Index: Acij4hsxyuwhOuasTOWlMUKiMZ/twQ== From: "Murty, Ravi" To: X-OriginalArrivalTime: 21 Apr 2008 19:01:30.0712 (UTC) FILETIME=[1BF64580:01C8A3E2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 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 19:01:31 -0000 Hello, =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 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 Thanks Ravi =20