From owner-freebsd-arch@FreeBSD.ORG Wed May 22 17:13:03 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4FA11FE; Wed, 22 May 2013 17:13:03 +0000 (UTC) (envelope-from oritm@mellanox.com) Received: from eu1sys200aog112.obsmtp.com (eu1sys200aog112.obsmtp.com [207.126.144.133]) by mx1.freebsd.org (Postfix) with ESMTP id 44AA077C; Wed, 22 May 2013 17:13:01 +0000 (UTC) Received: from MTLCAS01.mtl.com ([193.47.165.155]) (using TLSv1) by eu1sys200aob112.postini.com ([207.126.147.11]) with SMTP ID DSNKUZz8jm96DL3o6UN4bfegzqYWBSEUg2Rn@postini.com; Wed, 22 May 2013 17:13:02 UTC Received: from MTLDAG01.mtl.com ([10.0.8.75]) by MTLCAS01.mtl.com ([10.0.8.71]) with mapi id 14.03.0123.003; Wed, 22 May 2013 20:12:44 +0300 From: Orit Moskovich To: John Baldwin Subject: RE: FreeBSD spinlock - compatibility layer Thread-Topic: FreeBSD spinlock - compatibility layer Thread-Index: Ac5QiaSgCms1CiujRJ+uiUawknitKQEvjFEAACUK0bAAEntnAAAi8BtgAAhXzQAAB+r/oP//4/YAgABUGN4= Date: Wed, 22 May 2013 17:12:43 +0000 Message-ID: <981733489AB3BD4DB24B48340F53E0A55B0D4D32@MTLDAG01.mtl.com> References: <981733489AB3BD4DB24B48340F53E0A55B0CFD79@MTLDAG01.mtl.com> <201305220859.32948.jhb@freebsd.org> <981733489AB3BD4DB24B48340F53E0A55B0D3CD8@MTLDAG01.mtl.com>, <201305221105.55093.jhb@freebsd.org> In-Reply-To: <201305221105.55093.jhb@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.8.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 17:13:03 -0000 Thanks, I appreciate all your help!=0A= =0A= The section about the unbounded sleep wasn't included in the man page I've = read so I wan't familiar with that concept...(http://www.unix.com/man-page/= FreeBSD/9/locking/)=0A= =0A= =0A= =0A= ________________________________________=0A= From: John Baldwin [jhb@freebsd.org]=0A= Sent: Wednesday, May 22, 2013 6:17 PM=0A= To: Orit Moskovich=0A= Cc: freebsd-arch@freebsd.org=0A= Subject: Re: FreeBSD spinlock - compatibility layer=0A= =0A= On Wednesday, May 22, 2013 9:48:00 am Orit Moskovich wrote:=0A= > From the mutex man page " By default, MTX_DEF mutexes will context switch= =0A= when they are already held."=0A= > How is sleeping forbidden, but blocking on a mutex that might context swi= tch=0A= is ok?=0A= =0A= Because they are different. When you block on a lock you propragate your= =0A= priority to the lock holder and will resume execution if you are more=0A= important as soon as the holder drops the lock. In other words, you are go= ing=0A= to make forward progress.=0A= =0A= With "event" sleeps like *sleep() and condition variables, there is no owne= r=0A= to propagate priority to, and the sleep may very well be waiting for some= =0A= arbitrary event (such as the arrival of a network packet or completion of a= n=0A= I/O request), so there is not the same guarantee of making forward progress= .=0A= =0A= The other half of this that keeps this true is that you are not permitted t= o=0A= perform "event" sleeps while holding a mutex. You have to drop the lock wh= ile=0A= you wait which frees any threads waiting for the lock to run. When you blo= ck=0A= on a mutex the only thing you are ever waiting on is CPU time for either=0A= yourself or the lock holder to run.=0A= =0A= --=0A= John Baldwin=0A=