Execution Environment for Dynamically Scheduling Real-Time Tasks

Execution Environment for Dynamically Scheduling Real-Time Tasks L. B. Becker* & M. Gergeleit Institute for Distributed Systems (IVS) Otto-von-Guericke Universität Magdeburg, Germany {lebecker, gergeleit}@ivs.cs.uni-magdeburg.de * on leave from the Computer Science Institute, Federal University of Rio Grande do Sul, Brazil ABSTRACT This work presents an execution environment that guarantees the execution of dynamic real-time tasks without missing deadlines. To provide such feature the concept of TaskPairs is applied: each execution entity is divided into a MainPart, with possibly unknown timing behavior, and in an ExceptionPart, with know execution time. The integrated scheduling of both parts is done by a combination of scheduling strategies, one focusing in enhancing the CPU utilization and the other in guaranteeing the correct activation and execution of the exceptions. As the adopted scheduling strategies are based on the EDF algorithm, that is used according to its classical definition and also in a reverse-order EDF (Latest Release Time) this approach simplifies acceptance testing and scheduling drastically compared to prior implementations of TaskPairs. The proposed scheduler is implemented in the RT-Linux operating system. An overview of the ongoing work on enhancements of the environment is presented in the conclusions.

1

Introduction

The scheduler is the crucial component of a real-time system. It has to assign the resources to the tasks such that their timing requirements are met. The problem of guaranteeing deadlines in hard real-time systems has been solved by the use of off-line analysis of the application tasks. As example of scheduling algorithms that are suitable for dealing with such constraints are clockdriven algorithms and fixed-priority algorithms, like Rate Monotonic and Deadline Monotonic (an overview of these policies can be found in [Liu00]). A restriction of using such off-line analysis policies is that the resulting system is not able to cope with dynamic variations, like in the cases where: (i) workload may vary dynamically, (ii) Worst Case Execution Times (WCET) cannot

be computed, (iii) when changes in the environment are expected. Therefore, such applications need a scheduling component capable of handling uncertainty, possibly wrong timing parameters (due to their estimated nature), and dynamically changing behavior. This can be done by trading optimal functionality for timeliness, a wellknown strategy in fault tolerance. A timing fault occurs whenever the actual execution time of a task is greater than its deadline. The TAFT (Time-Aware FaultTolerant) scheduling [Str94; Net97; Net01] is able to handle timing faults in these uncertain environments such that deadlines are still met. This work presents an execution environment that makes use of the TAFT concept to implement a dynamic scheduler that guarantees the timely execution of real-time tasks. This environment uses a combination of scheduling strategies to achieve simple acceptance testing and small scheduling overhead at run-time. The remaining of this paper is divided as follows. In the next section it is given an overview of the TAFT scheduling and section 3 describes the exploitation of EDF-style algorithms for scheduling TaskPairs. Then, in section 4, the implementation of the execution environment is sketched and finally, in section 5 some concluding remarks are stated and the future extensions of the environment are discussed.

2

Overview of the TAFT Scheduling

In TAFT each task is designed as a TaskPair (TP) with a common deadline (DLTP). A TP constitutes a MainPart (MP) and an ExceptPart (EP), thus reflecting the mentioned fault-tolerance aspect. From the scheduler’s point of view, both parts are treated as separate scheduling entities having their individual timing parameters. The TAFT scheduler is a hard real-time

scheduler in the sense that it always guarantees the completion of either the MP or the EP before DLTP. However, an EP has to be executed if and only if its MP cannot be successfully completed before DLTP. This means the real functionality is implemented in the MP. The minimal functionality of the EP is to ensure that the respective TP leaves a) the controlled application in a fail-safe state and b) the controlling system in a consistent state. The timing parameter “execution time” is the WorstCase Execution Time (WCET) for the EPs Considering the MP, its execution time is interpreted as an ExpectedCase Execution Time (ECET) [Net01]. Roughly speaking, the ECET is a measure for the time that a certain percentage of instances of a task needs for a successful completion. Note that in most cases ECETs are considerably shorter than WCETs, and can also be obtained from a dynamic system by means of online monitoring. With the use of ECETs in TPs, the computational progress of a system can be preserved in the long term, even if WCET analysis of all tasks is impossible or a standard hard real-time scheduler fails to create a feasible schedule based on (longer) WCETs. For creating a schedule the internal deadline for an MP (DLMP) is equal to the latest releases time of its associated EP and DLEP. = DLTP. If an MP's execution exceeds its DLMP it is aborted. void Procedure_TP (deadline DL){ if(guarantee (TP, DL)){ try MP() Except EP() end } }

Figure 1: Programming a TaskPair Nevertheless, scheduling only the EPs is not enough for a successful implementation of the TP scheme. In addition, the MPs should be scheduled according to a strategy that maximize the processor utilization and that keeps a high level of MP completion. Therefore, besteffort scheduling mechanisms can be applied towards enhancing system optimization (but without providing execution guarantees), or dynamic real-time scheduling algorithms can be employed to keep a high processor utilization with the benefit of providing execution guarantees. Considering the structure of a TAFT application, the programmer must explicitly specify the parts of the TP when writing the code of the tasks. For that, the exception-style semantics shown in Figure 1 should be followed.

3

Adopted Scheduling Strategy

It was adopted a two-level1 dynamic scheduling strategy to schedule the tasks designed according to the TAFT approach described in the previous section. The first level is in charge of scheduling the EPs, while the second level is responsible for the MPs. The main reason for using separated scheduling policies is that MPs and EPs can be viewed as distinct tasks that have different eligibility policies. If possible, a MP should simply terminate before its deadline (DLMP), delays in the start time do not present conceptual problems. On the other hand, EPs have a severe restriction regarding their start times (STEP). It should occur as late as possible as an EP has to be executed if and only if the corresponding MP has not finished before. The initial idea was to schedule the EPs in a calendar-based2 manner [Str94]. However, implementing calendar-based algorithms presents many problems. The most obvious one is that a system based on this approach is brittle: It is relatively difficult and CPU consuming to modify and maintain dynamically. This has a direct consequence for the acceptance test: guaranteeing the timely execution of tasks in such an approach means finding an available time slot in the calendar or, in other words, calculating a new schedule. Moreover, this should be done not only when new tasks get into the system, but also when a periodic task that has already executed should be re-planned. In this sense, depending on the relation among the periods of the existing tasks, a plan for the largest cycle may contain lots of entries (consuming a lot of memory to be stored). Therefore, the Latest Release Time (LRT) algorithm (or reverse-EDF) [Liu00] was used to schedule EPs, representing the first-level scheduler. This algorithm treats release times as deadlines and deadlines as release times, scheduling the jobs backwards, starting from the latest deadline of all jobs, in a priority-driven manner, to the current time. In particular, the priorities are based on the release times of jobs: the later the release time, the higher the priority. The LRT algorithm is also optimal under the same conditions that the EDF algorithm [Liu73] is optimal. This means that EPs can be preempted by the occurrence of higher-priority ones. In addition, the EDF schedulability condition is also suitable for the LRT algorithm. Considering the MPs, the adopted scheduling policy is the EDF algorithm [Liu73]. One of the reasons is 1

According to [Liu00], n-level scheduling applies when more than one scheduling strategy is used in the same OS. 2 Also referred in the literature as clock-driven scheduling (see [Liu, 200]).

because the goal of MP scheduling is to enhance CPU utilization, and EDF is optimal regarding this aspect. Another reason is that it couples with the scheduling strategy adopted for the EPs, allowing the use of a single acceptance test, the EDF test, for the whole TP. This condition guarantees that a system of n independent, preemptable tasks, with relative deadlines equal to their respective periods, can be feasibly scheduled on one processor if and only if its total utilization is equal to or less than 1, as expressed by the following inequality: n

ek

∑p k =1

≤ 1 , where:

k

ek = ECETMPk + WCETEPk and pk = DLEPk It guarantees the execution of the EPs and it is at least a very good approximation for taking ECETs of MPs into account. In order to guarantee the timely execution of TPs, each newly arriving TP has to undergo the presented test. Its outcome is positive, if the scheduler can guarantee enough time for the TP to execute its MP plus its EP prior to DLEP. The behavior of the scheduler as described so far ensures that deadlines of TPs are never violated even if there is only a partial knowledge about their timing. The fact that it is not necessary to use the EDF pessimistic approach based on WCET offers a considerable advantage in the adopted scheduling strategy. The assumption that the WCETEP of an EP is known is not a severe restriction, as it is assumed to be a very short piece of code. Thus, even bad and very pessimistic execution time estimation should not lead to resource requirements that are comparable with those of the MP (ECETMP >> WCETEP). In general, this approach offers resourcesaving if WCETMP > ECETMP + WCETEP. As a result of the proposed scheduling strategy, two scheduling algorithms are cooperating to schedule the TPs. The LRT algorithm schedules the EPs in the firstlevel, while the EDF schedule the MPs in the secondlevel. The priorities generated as output from these two schedulers are divided in two separate classes. The LRT provides the highest priority output and the EDF the lowest. This means that if there is an EP ready to run, it will immediately preempt any MP from the CPU. Only if there are no EPs ready, than the EDF chooses which MP have the highest eligibility.

4

The Execution Environment

For implementing the scheduling strategy described above the RT-Linux operating system [Bar97] was used. The main reasons for choosing RT-Linux was that it provides a good dispatching mechanism (priority based,

like in the majority of the available real-time OS), and that it is an open-source program, allowing modifications to be done right in the original scheduler. The implementation of the proposed execution environment consisted on adding the two-layer scheduling policy previously described into the RT-Linux scheduler. This way, the result from the new scheduling policy (consisting in the MP or EP from an active TP) is passed to the original dispatcher, which is than in charge to put it to execute. The LRT-scheduler is considered the first-level scheduler because it provides the highest priority output. A timer is programmed for the instant that the EP should be triggered (DLMP), in order to guarantee the scheduler activation. Considering the jitter to treat an MP's abort, the worst case it is equal to the size of the operating system tick, which is 6.3 µs in the current implementation. At this moment, if the corresponding MP has not finished, than the EP will be forward to the dispatcher. Occurrences are automatically removed from the LRT queue when the MP terminates successfully, i.e. without violating DLMP. Each time a periodic task has its next activation reprogrammed, a new occurrence in the LRTscheduler is dynamically inserted. Once the first-level scheduler is processed, and no highest-priority output is generated, than the secondlevel one will be used to elect the next task to be run. This scheduler uses EDF algorithm to choose the next MP that will use the CPU. The result from this process will be in a lower level of priority than the one provided by the first-level. Again, its result will be send to the dispatcher. If there are no MPs ready for execution, than tasks running in the normal Linux mode will have the CPU control. To implement both the acceptance test and the scheduler itself, it was necessary to place additional information in the task descriptor structure originally defined in the RT-Linux environment: DLTP, ECETMP, and WCETEP. In addition, the current scheduler needs to keep updated information about the CPU utilization (based in the information given by the active task set). This information is used in the acceptance test for the new tasks. One of the most tricky implementation issues from this policy is aborting the MP and triggering the corresponding EP as soon as a deadline violation is detected. Two issues had to be considered: 1. The current instance of the MP has to be aborted, not just preempted. I.e. the thread had to be set in a state that allows for restarting it from the beginning in the next period. 2. While it would be easy to implement the EP in a real separate thread, this is not desirable. Exception handling is much easier if local state from the MP is

still available. This is the usual semantics of language-level exception. Also, from the schedulers point of view, it is not required to maintain two separate threads, as by definition the execution of the MP and the EP of one TP are mutual exclusive. The obvious approach to fulfill these requirements is a kind of setjump(), longjump() mechanism as known from Unix/C. This requires saving an initial state of the MP and, in case of an exception, putting the aborted MP back in that state and to initiate the EP from there. In contrast to the Unix/C mechanism, the longjump() operation is actually invoked by the scheduler, not by the executing thread itself. The setjump() mechanism is implemented by saving the stack pointer, and the longjump() accordingly by restoring the stack state. For implementation reasons this restoring is always performed in the context of a helper-thread, as it is quite difficult to manipulate the stack of a thread while inside its own context.

5

Conclusions and Future Work

This paper described the basic concepts and the prototype implementation of an execution environment for real-time applications based on TAFT, a dynamic scheduling policy and able to cope with timing faults. It uses a combination of EDF and LRT algorithms to achieve a simple acceptance test and an efficient run-time scheduling. An implementation based on the RT-Linux kernel is presented. One open issue is the underestimation of the CPU utilization in overloading situations. Since the TPs deadlines are equal to their period, the utilization factor calculated becomes invalid when the MP overrun the estimated ECET. Therefore, the utilization calculated in the acceptance test is not valid anymore (however, it has to be emphasized that the execution of the EP is always guaranteed). A possible solution for this problem is to decrease the task priority immediately after exceeding its ECET. This action changes the MP's status, i.e. from a guaranteed task it turns to be a best-effort task. In other words, the task will keep using the CPU only if there are no other guaranteed task ready for execution. Another aspect to be more elaborated is the acceptance test. The current test is proved to work when EDF is used and all WCETs are known. Since the current scheduler uses ECETs for the MPs and a combination of EDF and LRT algorithms it’s detailed properties are an issue of further analysis. Additional enhancements in the acceptance test would be to consider not only periodic tasks, but also sporadic ones. The authors already have in mind an application scenario where the presented execution environment would

be helpful. This scenario is a cooperative environment for autonomous mobile robots. Each robot is characterized by a including set of dynamic tasks that must be schedule on time to guarantee the quality of the performed actions. Failures in these actions can lead to a chaotic collaboration among the robots, incurring in undesired accidents and damages.

6

Acknowledgements

A special thanks is given to Prof. Edgar Nett, for collaborating with the discussions that preceded this paper. The authors would also like to thanks CAPES, from Brazilian Education Ministry, for providing the fellowship that allowed this cooperation work.

7

References

[Bar97] Barabanov, M. A Linux-based Real-Time Operating System. M.S. Thesis, New Mexico Institute of Technology, June, 1997. [Liu73] Liu, C.L., and Layand, J.W. Scheduling Algorithms for Multiprograming in a Hard-Real-Time Environment. Journal of the Assoc. for Computer Machinery 20(1). [Liu00] Liu, J.W.-S. Real-Time Systems. Prentice-Hall, 2000. ISBN 0-13-099651-3. [Net97] Nett, E. and H. Streich, The GMD-Snake - RealTime Scheduling of a Flexible Robot Application at Run-Time, Int. Workshop on Parallel Computation and Scheduling in Computers, Ensenada, Mexico, 1997. [Net01] E. Nett, M. Gergeleit, and M. Mock. “Enhancing OO Middleware to become Time-Aware”, Special Issue on Real-Time Middleware in Real-Time Systems, 20 (2): 211-228, March, 2001, Kluwer Academic Publishers. ISSN- 0922-6443 [Str94] Streich, H. “TaskPair-Scheduling: An Approach for Dynamic Real-Time Systems”. Proc. 2nd Workshop on Parallel and Distributed Real-Time Systems, Cancun, Mexico, April 28-29, 1994.