Re: msleep() on recursivly locked mutexes

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

_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages