From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 09:18:55 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 4B664106566C for ; Sun, 25 Jan 2009 09:18:55 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outo.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id 30DBE8FC08 for ; Sun, 25 Jan 2009 09:18:55 +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 0B4BA24D0; Sun, 25 Jan 2009 01:18:55 -0800 (PST) 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 A9E5F2D601A; Sun, 25 Jan 2009 01:18:54 -0800 (PST) Message-ID: <497C2E82.6010600@elischer.org> Date: Sun, 25 Jan 2009 01:18:58 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Jeff Roberson References: <497BA91D.805@elischer.org> <3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com> <497C235E.5090807@elischer.org> <20090124224716.X983@desktop> In-Reply-To: <20090124224716.X983@desktop> 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: Sun, 25 Jan 2009 09:18:55 -0000 Jeff Roberson 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. more or less what I was suggesting. > > What is the case you have where you can not acquire non leaf mutexes? > An example is netgraph. In netgraph you have one (or a small number) thread which is processing on behalf of a number of nodes which may be doing work on behalf of completely different entities. If such a worker thread blocks then other work becomes starved.. A similar example might be made for geom I expect. If a worker thread blocks other work can be starved. Now you still in these modules need some way to synchronize between threads to protect local resources etc. So you still want to be able to use mutexes for this but you wnat to be able to tell the module author "yes you can use mutexes but you can't do so in a way that introduces any threat of undetirminsitic blocking". i.e. once you have mutex in your node, to do something, do it quickly and drop teh mutex, and do NOT go acquiring something that might sleep on us. I'm already worried about people getting mbufs etc in netgraph, and it may turn out that we are already hitting this without knowing it..