From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 12:21:36 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 273AB16A407 for ; Wed, 14 Mar 2007 12:21:36 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.freebsd.org (Postfix) with ESMTP id C182713C46C for ; Wed, 14 Mar 2007 12:21:35 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so160656ana for ; Wed, 14 Mar 2007 05:21:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=udqedkLuLPz42i3Usns67emZDjJqKWFUMmfXJog8v2M078RpB8vf4dcoA+yAgeb8tyKiEpMrjys587AZpOvvJHSHNDRyO18FRYdEn1ISjDfCQsAOIZnTVIerL1m84ungBLZaiVwE1mlPzaHDHDWwCqWslp9Sb7m6fQCpKjcOOqk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=eFktHKCQQEwCJMaaRYjuJqAdecgeEqJQPi9fiyxN23m+JqhNIQl0rBmLu7VPQOi/sEPjv0FKuGKXvk4CmCOMuqQlhfstbGw4BL+oJnoByf8MReY7kYxU9Y/8WwL7yADA+FcQ3DiJgmMJ6QZBchR9GAEX3Abzfg8PyTUkMa8D/hk= Received: by 10.100.112.19 with SMTP id k19mr1619073anc.1173874894830; Wed, 14 Mar 2007 05:21:34 -0700 (PDT) Received: by 10.100.191.11 with HTTP; Wed, 14 Mar 2007 05:21:34 -0700 (PDT) Message-ID: <3bbf2fe10703140521x30e709c4g749a62b55f8aa61d@mail.gmail.com> Date: Wed, 14 Mar 2007 13:21:34 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Julian Elischer" In-Reply-To: <45F771E2.9050709@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200703092241.l29Mf2Ds062856@repoman.freebsd.org> <200703121535.22140.jhb@freebsd.org> <20070312200345.GB5688@garage.freebsd.pl> <200703121618.41084.jhb@freebsd.org> <45F5E1F9.5090806@elischer.org> <20070313010309.Q25395@fledge.watson.org> <45F73AE7.6010508@elischer.org> <45F771E2.9050709@elischer.org> X-Google-Sender-Auth: 7a04ec60357a8516 Cc: Robert Watson , Pawel Jakub Dawidek , current@freebsd.org Subject: Re: [RFC] locking.9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 12:21:36 -0000 2007/3/14, Julian Elischer : > Julian Elischer wrote: > > > > > ok so how about I commit this to get us started and the nroff and > > locking experts can take it from there. > > > > The first table I think may look like this > (from quick reading.. but I may be wrong): > > > The following table shows what you can and can not do if you hold one of > the synchronisation primatives discussed here: (someone who knows what > they are talking about should write this table) > > You have: You want: Spin_mtx Slp_mtx sx_lock rw_lock sleep > SPIN mutex ok no no no no-3 > Sleep mutex ok ok-1 no ok no-3 > sx_lock ok no ?? no ok-4 > rw_lock ok no no ok-2 no-3 > > *1 Recursion is defined per lock. lock order is important. > > *2 readers can recurse tough writers can not. lock order is important. > > *3 There are calls atomically release this primative when going to sleep > and reacquire it on wakeup (e.g. mtx_sleep(), rw-sleep() and > msleep_spin).() > > *4 One can also use sx_sleep() which atomically release this primative > when going to sleep and reacquire it on wakeup. I think that we can do a better job describing the three main events (spinning, blocking, sleeping) the correspondence with every primitive and what is allowed to do (we can add an addictional paragraph about preemption and its nits, sched_bind, sched_pin, critical sections, etc.). Assuming that lock ordering is always important (not only in the mutexes case) and that very soon all the primitives will allow recursion (check for //depot/user/attilio/attilio_smpng/... for an example fo recursive sx), it is not really important to deal with these details. I think would help having a section per-primitive describing the better cases of usage for every primitive, i.e.: Spin Mutexes - To be used only in interrupt context or for path really short, as single assignment etc (even if in that case probabilly they can be replaced by something more appropriate. This informations should be just integrative with the table you previously mentioned and should not overlap. Attilio -- Peace can only be achieved by understanding - A. Einstein