From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 19:34:23 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7333316A407; Fri, 27 Apr 2007 19:34:23 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe13.swip.net [212.247.155.129]) by mx1.freebsd.org (Postfix) with ESMTP id 600C913C46C; Fri, 27 Apr 2007 19:34:22 +0000 (UTC) (envelope-from hselasky@freebsd.org) X-Cloudmark-Score: 0.000000 [] Received: from [193.71.38.142] (account mc467741@c2i.net HELO [10.42.11.147]) by mailfe13.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 83177350; Fri, 27 Apr 2007 20:32:38 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Fri, 27 Apr 2007 20:32:20 +0200 User-Agent: KMail/1.9.5 References: <200704262136.33196.hselasky@c2i.net> <200704271917.29939.hselasky@freebsd.org> <46323A77.8010907@elischer.org> In-Reply-To: <46323A77.8010907@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704272032.20664.hselasky@freebsd.org> Cc: Daniel Eischen , Attilio Rao , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: msleep() on recursivly locked mutexes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2007 19:34:23 -0000 On Friday 27 April 2007 20:01, Julian Elischer wrote: > Hans Petter Selasky wrote: > > First of all: Where is FreeBSD's locking strategy document? > > It is just started.. > man 9 locking. it needs a lot of work still. Excellent. > > > We should have a > > global strategy when we write device drivers, so that various modules can > > be connected together without races and locking order reversals. > > > > In my view there are two categories of mutexes. > > > > 1) Global mutexes. > > > > 2) Private mutexes. > > > > Rule: The Global mutex is locked last. > > errr I'm not sure I'm following but this sounds kind-of reversed from > normal behaviour. Yes, it is. But you have to make a choice. Either this way or the other way. But not both! The reason for my choice is that I consider it to be more complicated to be a Global device than a private device. Complicated means that the Global device, which is locked last, has to unlock its lock before it calls back the "private" device, like I have explained below. Hence there are fewer Global devices (e.g. USB host controllers), then private devices (USB device drivers), we end up with less code/headache locking the Global devices last. If that is unclear I can explain more. > > > How do we organize this. > > > > 1a) The global mutex protects interrupts/callbacks into a hardware > > driver. This is the lowest level. > > > > 2a) Private mutexes protects sub-devices of the hardware driver. This > > might be as simple as an IF-QUEUE. > > I'm having trouble following already. > you mean subcomponents? Yes, children of devices. Sub-devices. > > > I have chosen the following model: > > > > P0 indicates process 0. P1 indicates an optional second process. > > > > Up-call: > > > > P0 lock(2); > > P0 lock(1); The work done [here] might be to setup DMA-able memory, and link it into the hardware. > > P0 unlock(1); > > P0 unlock(2); > > this looks "interesting". > Can you give a more concrete example of this? > what work is done in the upcall? WHo is upcalling to who? For example an USB device driver might be up-calling to the USB host controller driver. Down call is when the transfer finishes. > > > Down-call: > > > > P1 lock(1); > > P1 wakeup P0 // for example > > P1 unlock(1); > > pretty normal. > > > P0 //callback: > > P0 lock(2); // the new USB stack currently uses P1 here > > P0 unlock(2); > > > > > > > > Sure, in the up-call you lock #2 longer than lock #1, that is why lock #1 > > has got to be a short as possible. But it does not make sense to make > > lock #2 lock shorter than lock #1. I cannot see that the system will go > > faster that way. > > > > In the downcall I see no problems at all. #1 does its things as fast as > > possible. In parallell #2 can still execute, until the "callback". > > > > I hope you understand my semantics. > > > > What do you want to change from what I have explained? > > > > Any comments? > > > > My conclusion: If you want more paralellism, then use more mutexes. Don't > > try to push an existing mutex by unlocking it! > > that may or may not be true depending on how busy the mutex is.. > but I don't think there is an argument about this. > > > shouldn't this be somewhere other than "hackers"? I've CC'ed freebsd-arch. --HPS