From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 18:01:10 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 C8E4E16A402 for ; Fri, 27 Apr 2007 18:01:10 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outN.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id B4DFF13C487 for ; Fri, 27 Apr 2007 18:01:10 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 27 Apr 2007 10:28:13 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id A2062125B34; Fri, 27 Apr 2007 11:01:09 -0700 (PDT) Message-ID: <46323A77.8010907@elischer.org> Date: Fri, 27 Apr 2007 11:01:27 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Hans Petter Selasky References: <200704262136.33196.hselasky@c2i.net> <200704270748.49404.hselasky@c2i.net> <200704271917.29939.hselasky@freebsd.org> In-Reply-To: <200704271917.29939.hselasky@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Attilio Rao , freebsd-hackers@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 18:01:10 -0000 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. > 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. > > 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? > I have chosen the following model: > > P0 indicates process 0. P1 indicates an optional second process. > > Up-call: > > P0 lock(2); > P0 lock(1); > 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? > > 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"? > > --HPS