Re: serializing token

[Andrew Atrens <atrens@xxxxxxxxxxxxxxxxxx>]

Matthew Dillon wrote:
> :I didn't quite get this. Let's say a thread A is
> :holding token T, protecting list L. A is then
> :preempted by an interrupt and the interrupt thread
> :also tries to acquire token T. Are you saying that
> :interrupt thread will block when it tries to acquire T
> :(because A still owns the token even though thread A
> :belongs to the same LWKT scheduler/CPU as the
> :interrupt thread)? If this isn't correct, then how do
> :you guarantee that L is safe in A?
> :
> :Thanks so much for your answers!
> :
> :-J
>
>     Correct.  If an interrupt attempts to obtain the same token that
>     the thread it preempted owns, the interrupt will block.  This
>     will cause the original thread to be immediately resumed.  The
>     interrupt will then be rescheduled the next time a normal thread switch
>     occurs.

Sounds fair. You run, and get out of the way, and the interrupt thread 
waits for you. If you block, you go to the back of the line.. :)
>     Interrupts must be cognizant of these issues.  Time-sensitive interrupt
>     code cannot do things that might block for long periods of time.  FreeBSD-5

Agreed. I can't think of a case where this is not true ... :)

>     tries to handle this case by implementing priority borrowing but all
>     that really happens (in my view) is that FreeBSD-5 winds up hiding the
>     fact that there was a conflict in the first place.  Plus it unnecessarily
>     complicates the scheduler.

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


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