From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 17:22:05 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 D85C316A484 for ; Wed, 14 Mar 2007 17:22:05 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outW.internet-mail-service.net (outW.internet-mail-service.net [216.240.47.246]) by mx1.freebsd.org (Postfix) with ESMTP id 97E5413C45A for ; Wed, 14 Mar 2007 17:22:05 +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.32) with ESMTP; Wed, 14 Mar 2007 09:54:58 -0700 Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 9B032125ADA; Wed, 14 Mar 2007 10:22:04 -0700 (PDT) Message-ID: <45F82F3C.8080906@elischer.org> Date: Wed, 14 Mar 2007 10:22:04 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Attilio Rao 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> <3bbf2fe10703140521x30e709c4g749a62b55f8aa61d@mail.gmail.com> In-Reply-To: <3bbf2fe10703140521x30e709c4g749a62b55f8aa61d@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 17:22:06 -0000 Attilio Rao wrote: > 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. when you get a few moments, check it out and add these features :-) That's why I committed it.. to give people something to start with so that they can add to it if they have just a few minutes free. > > This informations should be just integrative with the table you > previously mentioned and should not overlap. > > Attilio > >