LIMITED PREEMPTIVE SCHEDULING - Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications - page 280

8.7.1 IMPLEMENTATION ISSUES

The preemption threshold mechanism can be implemented by raising the execution
priority of the task, as soon as it starts running. The mechanism can be easily imple-
mented at the application level by calling, at the beginning of the task, a system call
that increases the priority of the task at its threshold level. The mechanism can also
be fully implemented at the operating system level, without modifying the application
tasks. To do that, the kernel has to increase the priority of a task at the level of its
threshold when the task is scheduled for the first time. In this way, at its first acti-
vation, a task is inserted in the ready queue using its nominal priority. Then, when
the task is scheduled for execution, its priority becomes equal to its threshold, until
completion. Note that if a task is preempted, its priority remains at its threshold level.

In deferred preemption (floating model), non-preemptive regions can be implemented
by proper kernel primitives that disable and enable preemption at the beginning and
at the end of the region, respectively. As an alternative, preemption can be disabled
by increasing the priority of the task at its maximum value, and can be enabled by
restoring the nominal task priority. In the activation-triggered mode, non-preemptive
regions can be realized by setting a timer to enforce the maximum interval in which
preemption is disabled. Initially, all tasks can start executing in non-preemptive mode.
When τ i is running and a task with priority higher than P i is activated, a timer is set by
the kernel (inside the activation primitive) to interrupt τ i after q i units of time. Until
then, τ i continues executing in non-preemptive mode. The interrupt handler associated
to the timer must then call the scheduler to allow the higher priority task to preempt
τ i . Note that once a timer has been set other additional activations before the timeout
will not prolong the timeout any further.

Finally, cooperative scheduling does not need special kernel support, but it requires
the programmer to insert in each preemption point a primitive that calls the scheduler,
so enabling pending high-priority tasks to preempt the running task.

8.7.2 PREDICTABILITY

As observed in Section 8.1, the runtime overhead introduced by the preemption mech-
anism depends on the specific point where the preemption takes place. Therefore, a
method that allows predicting where a task is going to be preempted simplifies the
estimation of preemption costs, permitting a tighter estimation of task WCETs.

Unfortunately, under preemption thresholds, the specific preemption points depend on
the actual execution of the running task and on the arrival time of high priority tasks;