DragonFly kernel List (threaded) for 2004-04
Re: serializing token
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