DragonFly kernel List (threaded) for 2004-04
Re: serializing token
:VxWorks does this too, optionally, to prevent priority inversion
:problems from killing the real-time performance of a system.
:On VxWorks you can optionally create mutexes with what they call
:'priority inversion protection'.
:A classic example of a priority inversion happening in the field is in
:the story of the Mars rover from a few years ago now. -
:Priority inversion protection is essentially just priority-borrowing -
:basically the lower priority task gets boosted to the priority of
:highest priority task waiting for the resource to allow it to 'get out
:of the way'.
Yes. It sounds great in concept, but it just hides the fact that
the priority process was badly coded. You can't truely protect
against long latencies in critical subsystems unless you can guarentee
that no conflicts will occur.
The DragonFly programming model attempts to make it possible to write
algorithms where no conflicts actually occur. The LWKT scheduler is a
:> The real solution to such conflicts is to rewrite the interrupt code to
:> not conflict (just like we did in times of old). DragonFly has ample
:> mechanisms available to the programmer to be able to do this fairly
:> easily (things like critical sections, messaging, direct access to
:> per-cpu caches, and so forth).
:Now a stupid question, I've been following the descriptions of what a
:serializing token is, and if I'm understanding, a serializing token
:while you are holding it, guarantees that you are the only one running
:on a given cpu until you block or release the token. Is it as simple as
Yes. That is all there is to it. It doesn't mean that you can just
use a serializing token anywhere without consequences, you would not want
to use tokens inside a latency-critical interrupt, for example. Tokens
are best used in mainline code (e.g. the vnode interlock).
I would consider the token abstraction to be a lot easier to program to
then the mutex abstraction. The lack of atomicy actually makes things
easier to write, believe it or not. It may seem backwards but not
being able to depend on atomicy means that you will write code that
is tolerant of blocking situations which in turn has the effect of
allowing the code to be more flexible (in that it is able to call other
subsystems without having to make assumptions as to whether they might
block or not). A great deal of FreeBSD-5 code, on the otherhand, must
make huge assumptions as to the exact side effects of a subroutine call
made between subsystems, because if something might block you have no
choice but to pass your held mutex (only one) into that routine so it
can be released prior to blocking, which in turn requires an extremely
inflexible implementation of many subroutines and creates a situation
that makes it really easy to accidently introduce new bugs into the