From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 06:53:41 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 956981065674 for ; Mon, 26 Jan 2009 06:53:41 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outX.internet-mail-service.net (outx.internet-mail-service.net [216.240.47.247]) by mx1.freebsd.org (Postfix) with ESMTP id 7786D8FC19 for ; Mon, 26 Jan 2009 06:53:41 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id A34FE24AC; Sun, 25 Jan 2009 22:53:41 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id B19B32D6017; Sun, 25 Jan 2009 22:53:40 -0800 (PST) Message-ID: <497D5DF8.8000706@elischer.org> Date: Sun, 25 Jan 2009 22:53:44 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Alfred Perlstein References: <497BA91D.805@elischer.org> <3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com> <497C235E.5090807@elischer.org> <20090124224716.X983@desktop> <20090125092838.GC87077@elvis.mu.org> In-Reply-To: <20090125092838.GC87077@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Kip Macy Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2009 06:53:41 -0000 Alfred Perlstein wrote: > * Jeff Roberson [090125 01:21] wrote: >> On Sun, 25 Jan 2009, Julian Elischer wrote: >> >>> Kip Macy wrote: >>>> The adaptive spinning of regular mutexes already satisfies your need >>>> for "short" hold. You might wish to add a thread flag used when >>>> INVARIANTS is enabled that is set when a leaf mutex is acquired and >>>> checked on all mutex acquisitions. >>> ummm that was what I was asking for.. an official designation of a 'leaf' >>> mutex... >> It'd be much easier to add the flag as a mtx_init() flag and have witness >> check it. It'd only take 15 minutes to do properly. >> >> What is the case you have where you can not acquire non leaf mutexes? > > Jeff, I think that Julian really wants to prevent a sleep inside > his context. Right now, I think we only check for mutexes held > before a sleep that arne't sleepable. It might make sense to allow > one to just mark a thread non-sleepable even though no mutex is > held. > > Julian, is that right? basically, though I don't know the details of implementation.. I just know that mutexes per se aren't bad for netgraph but that node authors need some guidance on how to use them and some way to prove to them when they do the wrong thing. > >> Thanks, >> Jeff >> >>>> -Kip >>>> >>>> On Sat, Jan 24, 2009 at 3:49 PM, Julian Elischer >>>> wrote: >>>>> Currently we have: >>>>> spin locks.. >>>>> you really don't want to hold these for >>>>> any time at all, and this is enforced to some extent in the waiter. >>>>> >>>>> regular mutexes.. >>>>> You can hold these for as long as you want but teh shorter >>>>> the better and you can't sleep when holding them. The >>>>> "shortness" of the time of holding the mutex is not enforced. >>>>> >>>>> "Sleeps" (including sx-locks and friends) >>>>> You may hold these or be descheduled for really long periods of time. >>>>> >>>>> >>>>> Now it occurs to me that there is a subclass of regular mutexes, >>>>> usage, which is where you want to use a mutex to guard some small >>>>> but critical structure, and that you know that access to that structure >>>>> will >>>>> be quick, and that you can guarantee that you will >>>>> not acquire any other locks (which could introduce unknown delay) >>>>> while hoding the lock. >>>>> >>>>> One way of thinking about this is that this lock would always be >>>>> a leaf node on the tree of lock orders. >>>>> I would like to be able to add a flag to a mutex >>>>> that tags it as a 'leaf' mutex. As a result it would be illegal >>>>> to take any other mutex while holding a leaf mutex. Somewhat >>>>> similar to the way that it is illegal to take aregular >>>>> mutex while holding a spin mutex.. >>>>> >>>>> >>>>> In netgraph I have a stipulation that is hard to specify which >>>>> is that you MAY take a mutex in a netgraph node if you can guarantee >>>>> that the mutex WILL be satisfied very quickly, but it'd >>>>> be nice to be able to specify "you may only take 'leaf' mutexes within an >>>>> netgraph node". >>>>> >>>>> >>>>> thoughts? (especially from jhb and other locking types). >>>>> >>>>> >>>>> _______________________________________________ >>>>> freebsd-arch@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >>>>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >>>>> >>> _______________________________________________ >>> freebsd-arch@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >>> >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >