serializing token

Andrew Atrens atrens at nortelnetworks.com
Sat Apr 24 20:57:18 PDT 2004


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.







More information about the Kernel mailing list