From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 01:15:30 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 60A201065689 for ; Sun, 25 Jan 2009 01:15:30 +0000 (UTC) (envelope-from prvs=julian=2693e0778@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 4EE238FC17 for ; Sun, 25 Jan 2009 01:15:30 +0000 (UTC) (envelope-from prvs=julian=2693e0778@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.85]) by smtp-outbound.ironport.com with ESMTP; 24 Jan 2009 15:49:46 -0800 Message-ID: <497BA91D.805@elischer.org> Date: Sat, 24 Jan 2009 15:49:49 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: 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 01:15:30 -0000 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).