DragonFly BSD
DragonFly kernel List (threaded) for 2004-04
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: serializing token

From: Andrew Atrens <atrens@xxxxxxxxxxxxxxxxxx>
Date: Sat, 24 Apr 2004 23:57:18 -0400

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!

    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

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


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 ?


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]