From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 09:37:28 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 659C0106566C; Sun, 25 Jan 2009 09:37:28 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 465558FC13; Sun, 25 Jan 2009 09:37:28 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 7097A1A3C3B; Sun, 25 Jan 2009 01:28:38 -0800 (PST) Date: Sun, 25 Jan 2009 01:28:38 -0800 From: Alfred Perlstein To: Jeff Roberson Message-ID: <20090125092838.GC87077@elvis.mu.org> References: <497BA91D.805@elischer.org> <3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com> <497C235E.5090807@elischer.org> <20090124224716.X983@desktop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090124224716.X983@desktop> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org, Julian Elischer , 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: Sun, 25 Jan 2009 09:37:28 -0000 * 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? > > 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" -- - Alfred Perlstein