[coyotos-dev] Need for revised invocation

[Jonathan S. Shapiro]

Charlie:

Initially, I did not understand what you mean when you say "resumption
is not preemption". Your "infinite processors" test did finally clarify
it for me: resumption is the special case of preemption in which, if you
had an infinite number of processors, you never need to unload and
reload their state.

But having said that, you go on to agree that there exist *some* idioms
requiring preemption -- notably event loops -- that are okay. This
suggests to me that there is a more subtle issue hiding here that is
ultimately an aesthetic judgment. I suspect that we actually agree about
that judgment and we are arguing about a difference in implementation.
Specifically: you do not really address the kernel vs. user threading
issue.

>From the perspective of mechanism, kernel-implemented preemption and
user-implemented preemption are essentially similar. In the kernel
thread case, the thread is halted by the kernel and the kernel resumes
some other thread. Similarly, in the user-mode thread case, the
activation handler interrupts one user-mode thread and may elect to
resume a second one. In the kernel case, the kernel is aware of
preemption but the application need not be. In the activation handler
case, the activation handler is aware of preemption but the user-mode
"worker" threads need not be.

Because the mechanisms are essentially identical, I do not believe that
the user-mode case should be viewed as qualitatively different from the
kernel-mode case. Concurrency is certainly tricky and error prone, but
this is orthogonal to whether the concurrency is managed at kernel level
or user level. It seems to me that any argument concerning preemption
must apply co-equally in both cases.

I believe we agree that in the absence of a compelling requirement,
awareness of preemption should exist only within the runtime system.
What we are really debating is whether the line between application and
runtime should be at the user/supervisor boundary or someplace else.
There are compelling performance arguments that it should not be
restricted to the user/supervisor boundary.


Unfortunately, there exist applications with a compelling requirement:
multimedia applications. These applications absolutely MUST know when
certain preemptive events occur -- notably the start of their guaranteed
scheduling slot. They need to know this because they require the ability
to synchronize their processing behavior to external events. A second
example is high-speed network stacks. In both cases, the incoming event
will be "posted" to an application-level event loop for later
processing. The main difference vs. pure event-driven processing is that
a global variable will get set by the runtime indicating that a
high-priority event has arrived, and some of the event handlers may poll
this variable and voluntarily abandon their work.


shap