Date: Fri, 27 Apr 2007 11:01:27 -0700 From: Julian Elischer <julian@elischer.org> To: Hans Petter Selasky <hselasky@freebsd.org> Cc: Daniel Eischen <deischen@freebsd.org>, Attilio Rao <attilio@freebsd.org>, freebsd-hackers@freebsd.org Subject: Re: msleep() on recursivly locked mutexes Message-ID: <46323A77.8010907@elischer.org> In-Reply-To: <200704271917.29939.hselasky@freebsd.org> References: <200704262136.33196.hselasky@c2i.net> <200704270748.49404.hselasky@c2i.net> <Pine.GSO.4.64.0704270906001.8536@sea.ntplx.net> <200704271917.29939.hselasky@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46323A77.8010907>