serializing token

[Matthew Dillon]

: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 at xxxxxxxxxxxxx>