DragonFly kernel List (threaded) for 2004-04
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
re: serializing token
: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.
Interrupts must be cognizant of these issues. Time-sensitive interrupt
code cannot do things that might block for long periods of time. FreeBSD-5
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.
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).
-Matt
Matthew Dillon
<dillon@xxxxxxxxxxxxx>
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]