msleep() on recursivly locked mutexes
Julian Elischer
julian at elischer.org
Fri Apr 27 18:01:10 UTC 2007
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
More information about the freebsd-hackers
mailing list