Table 5.1: Time and space complexities of dierent TOPS's scheduler TOPS-c TOPS-l TOPS-m time complexity
O
(1)O
(n
)O
(logn
) space complexityO
(b
n=b
1)O
(n
)O
(n
)Each job scheduled using TOPS-m starts as is predicted but TOPS-m tries to nish the job as soon as it can. Therefore, the job using TOPS-m tends to nish earlier than expected. In other words, it has a better response time. Since we need to maintain the priority-queue, TOPS-m has an
O
(logn
) time complexity. It has the same space complexity as TOPS-l.The time and space complexities of the above TOPS's is summarized in Table 5.1.
70
Tasks may have unpredictable execution time.
Periodic tasks may not allow period transformation.
Tasks may arrive and leave dynamically.
There are non-real-time tasks.
5.3.1 Unpredictable Execution Time
In a practical system environment, it is inevitable for tasks to have unpredictable execution times. If we always use the worst case execution time, the system utilization will be very low. Therefore, a more realistic execution time estimation is usually adopted. All TOPS algorithms in Section 5.2.2 can handle task underruns: the system remains idle when a job
nishes earlier than expected. If a job overruns, however, we must provide damage control so that other jobs are not aected. One option is simply to abort the job in the hope that some imprecise result may still be produced. Another option is to move the overrun job to an overrun-queue and try to nish the job later. The jobs in the overrun-queue can be run in a FIFO fashion when the system is idle. When a job overruns, we will still set a timer event to run its next job at the pre-dened start time, so that the next job may nish in time and the overrun job does not aect other real-time jobs. All TOPS schedulers can be modied to handle the overrun in this way.
5.3.2 Fixed Period Tasks
If a task is schedulable using the distance-constrained model but actually does not allow its execution period to be changed, it can be transformed back to the periodic mode and is still schedulable21]. If the periodic tasks accept more frequent executions, we can use the periods as distance constraints to do the pinwheel transformation. All above TOPS's can be applicable as well. However, if the periodic tasks do not allow period transformation, the TOPS's need to be modied. For aperiodic tasks, we can use the minimum inter-arrival time as distance constraint to reserve execution time for them. Since the aperiodic tasks arrive unpredictably, more sophisticated mechanism (such as in 45]) is needed to improve
system utilization. The sporadic task case will not be discussed here but left as future work.
Hereafter in this section, the periodic tasks refer to only tasks that do not allow period transformation. We still can create a dummy job with the same execution time and the transformed period to reserve execution time for each periodic job at the start time and resume times of the dummy job. The periodic job is ready at time 0. It can only execute when the system is reserved for it otherwise, the periodic job is moved to a reserve-queue.
When the dummy job reserves the execution time for a periodic job, it checks if the periodic job is in the reserve-queue. If it is, the job is removed from the reserve-queue and executed.
The dummy job does not execute in the reserved execution time. Once the periodic job starts executing, it is preempted and resumed as a distance-constrained job. No reservation is needed anymore before it nishes. When the periodic job nishes, a timer event is set to run next job at the beginning of its next original period. The dummy job will still reserve the system at the start time of next transformed period.
Two operations reserve and cancel are created to reserve the system for a periodic job and cancel the reservation respectively. In the following, a scheduler modied from TOPS-l, called TOPS-lp, is designed to handle the periodic tasks. TOPS-lp is more complicated due to the reservation scheme but has the same complexity as TOPS-l.
72
Algorithm TOPS-lp
: TOPS-l with periodic task handling Input: DCTST
=fT
i = (e
ib
ic
is
if
i)j 1i
n
g Output: On-line pinwheel schedule execution.1
foreach T
i2
if
(T
i is periodic), f3 set timer event: at time
s
i,reserve
(J
i1s
i).4 set timer event: at time
f
i,cancel
(J
i1). // cancel reservation forJ
i1.5 set timer event: at time 0,
run
(J
i1).6 g
7
else
set timer event: at times
i, runJ
i1.8
while
(true)f9 wait for events
10
if IsEvent
(J
ki nishes),11
if
(J
ki is periodic), set timer event: at timek c
i,run
(J
ik+1).12
else
set timer event: at times
i+k b
i, runJ
ik+1.13
elseif IsEvent
(J
ki is interrupted at timet
) f // current jobJ
ki is preempted.14 set timer event: at time
NextIdle
(t i
), resumeJ
ki.15 launch the action dened for this event
16 g
17
else
launch the action dened for this event // a scheduled start/resume time event.18 g
reserve
(J
kit
) //t
is the time the event which launched this action raised.1
if
(J
ki is not reserved), markJ
ki as reserved.2
if
(J
ki is in reserve-queue), remove it from reserve-queue and run it3
else
set timer event: at timeNextIdle
(t i
),reserve
(J
kiNextIdle
(t i
)).cancel
(J
ki)1 mark
J
ki as not reserved.2 set timer event: at time
s
i+k b
i,reserve
(J
ik+1s
i+k b
i).run
(J
ki)1
if
(J
ki is not reserved), moveJ
ki to reserve-queue2
else
runJ
ki.5.3.3 Dynamically Arriving and Leaving Tasks
In a real-time system, the system parameters are usually known a priori so that the pre-dictability can be provided. To deal with task arrivals and departures dynamically without a prioriknowledge, the predictability inevitably will be compromised. For example,
EDF
is a commonly used dynamic scheduling algorithm. It provides the optimal schedulability only if there is no overrun, and then it only guarantees tasks will nish before their deadline.
It is dicult to predict when the tasks will start or nish. It is also dicult to detect and deal with overrun cases in
EDF
.In our time-driven approach, since the eective schedule can be generated on-line in polynomial time, it provides a better predictability. We can recalculate the eective sched-ule if there is new task arriving. When we redo the schedulability test, we can choose the distance-constraint transformation so that the distance constraints of the existing tasks are not changed. However, the previous schedule can not be guaranteed if we apply the new eective schedule at once. If we can delay the application of the new eective schedule to the next ready time of one of the tasks with a higher priority than the arriving or leaving tasks, the schedule of tasks with higher or equal priority to the task will not be changed and those tasks are still predictable as well. For tasks with a lower priority than the arriving or leaving tasks, they are also predictable in the new eective schedule. We may run the job from previous eective schedule in background or preallocated execution time for this transition purpose to improve predictability.
For leaving tasks, we can leave the system idle in their execution times or reserve their execution times for non-real-time tasks. Thus, no schedule of real-time tasks is aected.
If we recalculate the eective schedule at the end of previous eective schedule, a better utilization than leaving the distance constraint of existing tasks unchanged may be achieved and the eect of unpredictability is also reduced.
Another approach to handle dynamically arriving and leaving tasks is to predene several distance constraints for tasks which arrive more often and preallocate execution time for these tasks. If the arriving task is with one of the predened distance constraints after distance constraint transformation, part of the execution time is allocated to this new task. Basically, we can reuse the execution time of the predened tasks for the dynamic tasks. If the transformed distance constraint is not predened, we can further transform the arriving task to t the predened distance constraint by changing the execution time
74 for the task. This approach provides the best predictability but less schedulability. The predened task set can also be changed to accommodate the dynamic scenario.
5.3.4 Non-real-time Tasks
In a real-time system, non-real-time tasks usually run in a round-robin fashion when the system is idle. The round-robin mechanism denes a constant time slice for all tasks. The context switch happens when task nishes or the time slice is exceeded. The round-robin solution applies to the above TOPS's as well. However, since we can predict how much and when the system is idle using the time-driven approach, we can dynamically change the size of time slice to avoid unnecessary context switching. For example, when we start a task in a time slice and set a timer event to do context switching to next task at the beginning of next time slice, if we know another timer event is going to preempt the next task soon, the context switch timer event can be ignored.
Moreover, the time slice for each task can be set proportional to its estimated execution time in a system idle duration provided that the response time is acceptable. The response time can be controlled by a largest time slice limitation. More sophisticated optimization can be done. This is left as future work.
5.3.5 OS Extension and Hardware Support
Real-time features have been moved from special-purpose or embedded operation systems into general-purpose operation systems for many years. The reasons to use general-purpose OS to support real-time features include accessing the rich set of the general-purpose OS features and accessing the available o-the-shelf applications, utilities, and services. The purpose is to provide a general application programming interface (API), or OS extensions, so that both non-real-time and real-time applications can be implemented eciently under the same environment. Some hardware supports for the OS extensions are necessary to improve performances. However, some OS extensions can still be done solely in software for the cost-eective concern.
We assume the OS supports thread programming and has enough priority levels for the applications. Each task is implemented using a set of threads. When we preempt a task, all its threads are suspended when we resume a task, all its threads are awaken. We also assume there are enough resources or the critical section is negligible so that no resource sharing conict needs to be solved. The problems of resource sharing are left as future work.
To implement a time-driven scheduler, a precise timer is critical. This needs to be done by a fast system clock and an ecient timer interrupt. A real-time timer can be designed to examine the time slice in hardware and generate a timer interrupt when it is expired.
A separate timer event queue is also desirable because specic optimizations can then be done on it.
Beside timer interrupt handling, we assume the interrupt service routine is realized as a thread and can be executed as a real-time aperiodic task when the system is running real-time tasks. Therefore, it does not aect the execution of real-time tasks. There is also an interrupt masking mechanism to prevent further interrupting before the previous interrupt is serviced. Using the time-driven approach, it is easy to know when a real-time task or a non-real-time task is running. When the system is running non-real-time tasks, the interrupt behaves the same as in a conventional OS, i.e., no special handling is needed.
The dierent interrupt handlings for real-time and non-real-time tasks can also be done in hardware for better performance.
We do not need special I/O devices, e.g., real-time cache, DMA controller 23] to im-plement the time-driven approach. Even the hardware real-time timer is not mandatory.
With the OS extensions and using our TOPS's, there is no context switching during the execution of real-time tasks until a timer event is raised provided that the interrupt masking is enforced. This is an important feature and will improve system performance a lot.
76