Re: serializing token

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:
: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. -
:
:http://www.cs.duke.edu/~carla/mars.html
:
: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
    great example.

:>     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
:that ?
:
:Andrew.

    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
    system.

					-Matt	
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>