From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 09:11:54 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 6731F1065675 for ; Sun, 25 Jan 2009 09:11:54 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id 38D918FC1E for ; Sun, 25 Jan 2009 09:11:54 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5536350rvf.43 for ; Sun, 25 Jan 2009 01:11:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=worrHFJ+m8UY8pQPxH+OucmlgoPtgl5WvN72Y5Ao7uw=; b=HpeYrZqndk8IcCCo1rOcF5uEtseTbUQfZzAH4OKnJmxzEen9petQGHWZHG0XHbIDLv Q1sNBCXkeUEDMffY6uDrO2YdivYlXAtOZIJzUNJI8LwXK9dHByScR1cqNoWoSsBwAzrw FW115YHPnqn1Ekpub5Gw6GznHcl3m2M235xOA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=sZX+y66n9yMbs6Aiig0QFkP3YZ7hesyO/VYOzH6fne6nf4Js95Iix+NUPPMeC5dmf2 sasGbw2Z4jJVKtUlRlMVaQXK3Ov1xd/gEWKERjLSJyBWITVXzy58+QFuqi5kkG0ZfqfJ F1g7q+aYm8XWx90Qo6Z1zvKdyUOFJM6gxGZUQ= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.141.82.20 with SMTP id j20mr920761rvl.190.1232874713721; Sun, 25 Jan 2009 01:11:53 -0800 (PST) In-Reply-To: <497C235E.5090807@elischer.org> References: <497BA91D.805@elischer.org> <3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com> <497C235E.5090807@elischer.org> Date: Sun, 25 Jan 2009 09:11:53 +0000 X-Google-Sender-Auth: 25717fad44469c2e Message-ID: <3c1674c90901250111w34f9d016xb8e812cf46433970@mail.gmail.com> From: Kip Macy To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org 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:11:54 -0000 On Sun, Jan 25, 2009 at 8:31 AM, 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... uhm ... I was explaining a way to implement it without WITNESS. -Kip > >> >> -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" >>> > >