Scalable Multi-Tasking using Preemption Thresholds Manas Saksena Department of Computer Science University of Pittsburgh Pittsburgh, PA 15260, USA manas@cs.pitt.edu Yun Wang Department of Computer Science Concordia University Montreal, QC H3G 1M8, Canada y wang@cs.concordia.ca Abstract Preemptive multi-tasking is a commonly used architecture for designing and implementing embedded real-time software. However, preemptive multi-tasking comes with its own costs. These costs include overheads due to preemptions and context-switches that result in waste of CPU bandwidth. Also, each task incurs a memory cost largely due to the need to maintain a separate stack for each task. These costs increase with the number of tasks and can be significant in complex real-time software. In this paper, we propose results from our ongoing research in which we are developing a design method with scalable multi-tasking implementations for complex realtime software. Our design method is based on an extension of fixed priority preemptive scheduling using preemption thresholds that was proposed in [15]. Using this new scheduling model we show how we can design multi-tasking implementations that are far more scalable than using pure preemptive multi-tasking implementations. 1. Introduction Preemptive multi-tasking is widely used as an implementation architecture for real-time systems, and is supported by virtually all real-time operating systems. There are clearly many benefits of preemptive multi-tasking, especially as compared to the traditional cyclic-executive model of developing real-time systems [9]. It allows efficient use of resources at run-time, and can be used to get small latencies for more urgent tasks. Also, with the advancements in real-time scheduling theory, it is possible to analyze suitably restricted implementations for schedulability. The most popular and well-developed analysis, often known as generalized ratemonotonic analysis [8], is based on fixed priorities for tasks The scheduling model is based on recurring periodic and sporadic tasks. Periodic tasks recur periodically with a fixed inter-arrival time, i.e., its period, and are triggered by a periodic timer. Sporadic tasks, on the other hand are triggered by an aperiodic event (e.g., an interrupt), and have a minimum inter-arrival time (which is also called its period). A task is assumed to perform a bounded amount of work on each release, which is characterized by its worst-case execution time. The benefits of preemptive multi-tasking come with a cost. These costs include loss of CPU bandwidth due to preemptions and context switches. Also, there is a pertask memory cost, largely due to the the need to maintain a separate stack for each task. In systems with small number of tasks, the advantages of preemptive multi-tasking clearly outweigh the disadvantages due to the costs. However, these costs also make scalability a problem for complex real-time software which can have a large number of tasks. Identification of tasks is a crucial step in real-time software design and implementation [6, 4]. Some design methods (e.g., DARTS [6], HRT-HOOD [3]) propose early identification of tasks and use tasks as structuring units. On the other hand, many object-oriented design methods defer identification of tasks to late design stage (e.g., ROPES [4], ROOM [12], and OCTOPUS [1]). In either case, an important influence on task identification is performance concerns, which includes meeting the real-time responsiveness requirements and minimizing run-time overheads.
Events are retrieved from from a priority queue. Process event by calling an appropriate function. Initialize Wait for Event Process Event Terminate Figure 1. Behavior of an Event-Handling Task While in simple systems it may be possible to create a task for each external and internal event, this is usually not feasible in complex systems that may have hundreds of possible events. A large number of tasks results in both loss of CPU bandwidth and increased memory overheads. This is especially significant when tasks are fine-grained, as would be likely if each event was handled in a separate task. Consequently, most design methods provide guidelines to group events into tasks for implementation [4, 12, 6, 1]. As a result of this grouping of events, each implementation task, in general, performs multiple functions by handling multiple event streams from possibly several sources. In object-oriented designs it is common to group all requests to one or more objects in a single implementation task [12, 1]. For example, the MARS Pathfinder system used such an implementation architecture [13]. In this implementation architecture, each task is implemented as an event handler as shown in Figure 1. A task has an event queue, where events are queued upon arrival or generation. Events may arrive from external sources (e.g., interrupts), be generated by passage of time (through timer services) and may be explicitly generated by other tasks (internal communication using message passing). In each iteration of the event handling loop, a task processes one event. While the use such event-triggered multi-tasking reduces costs of multi-tasking due to fewer tasks, it creates a difficulty for the designer to decide on a suitable implementation architecture for a given design. A designer must now decide on how many tasks to use and how to map events to tasks. Clearly, the choice of the implementation architecture must be guided by schedulability constraints. Unfortunately, this event-triggered task model conflicts with the basic assumptions of generalized rate-monotonic scheduling theory since a task may be processing events with different timing requirements (arrival rates and deadlines) and different execution times. The implementation model also results in non-preemptability into the scheduling model since within each task, events are processed in a run-to-completion manner. In this paper, we present results from our ongoing research in which we are looking at schedulability analysis and automated synthesis of event-triggered multitasking implementations, especially in the context of objectoriented designs. Our approach is based on a new scheduling model that extends fixed priority preemptive scheduling using preemption thresholds [15]. We show that this new scheduling model serves as a basis for scalable event-triggered multi-tasking as described above. The new scheduling model allows us to assess schedulability of a particular implementation architecture, which, in turn, provides a basis for automatic synthesis of a scalable implementation architecture from a design model. The rest of the paper is organized as follows. In Section 2, we present the new scheduling model and show its benefits over fixed priority, preemptive scheduling. Then, in Section 3, we show how to make use of the new scheduling model for designing scalable multi-tasking implementations. Finally, we present two simple case studies that highlight the benefits of our approach. 2. Preemption Threshold Scheduling Model The preemption threshold scheduling model is an extension of fixed priority preemptive scheduling model. In this scheduling model, each task has a preemption threshold, in addition to its priority. In essence this results in a dual priority system. Each task has a regular priority, which is the priority at which is is queued when released. Once a task gets the CPU, its priority is raised to its preemption threshold. It keeps this priority until the end of its execution. For recurring tasks, this process repeats each time the task is released. The response time analysis for this scheduling model is similar to the standard response time analysis for fixed pri-
ority preemptive scheduling using the notions of critical instant and busy periods [8]. In [15] we developed the response time analysis for a set of periodic and sporadic task sets for this scheduling model. While the scheduling model is relatively simple, it provides many benefits by integrating the best of preemptive and non-preemptive scheduling models. The following sub-sections highlight some of the benefits of the scheduling model as well as how to determine feasible scheduling attributes (priorities and preemption thresholds) for tasks. 2.1. Integration of Preemptive and Non-Preemptive Scheduling The preemption threshold scheduling model integrates and subsumes both preemptive and non-preemptive scheduling models. If the preemption threshold of each task is the same as its priority, the model reduces to pure preemptive scheduling. On the other hand, if the preemption threshold of each task is the highest priority value, then we have the case of non-preemptive scheduling. By choosing an appropriate preemption threshold value, we are potentially able to take advantage of the best of both preemptive and non-preemptive scheduling models, and in fact do better than either. In the context of fixed priority scheduling, it is easy to construct example task sets that are schedulable under preemptive scheduling but not under non-preemptive scheduling and vice-versa. Since, the preemption threshold scheduling model is a generalization of both the preemptive and non-preemptive scheduling models, it follows that it dominates both preemptive and non-preemptive scheduling models. That is, if a task set is schedulable under either preemptive or non-preemptive scheduling, then it is also schedulable using preemption thresholds. Moreover, we can construct task sets that are schedulable with preemption thresholds, but not schedulable under either preemptive or non-preemptive scheduling. Also, using simulations over randomly generated task sets we have seen that using preemption thresholds we can increase the breakdown utilization by as much as 10-15% in a significant percentage of task sets. 2.2. Assignment of Feasible Scheduling Attributes For both preemptive and non-preemptive scheduling, an optimal algorithm exists that can find a feasible priority assignment for a set of periodic and sporadic tasks with arbitrary deadlines [14, 5]. The problem of finding feasible scheduling attributes is significantly harder with preemption threshold scheduling due to the extra attributes (each task has a priority and preemption threshold) and the non linear relationships between the attributes and their effect on response times. In [15] we presented an efficient algorithm to find feasible preemption thresholds for a given priority assignment. Using that algorithm as a base, we have developed (a) an optimal, but expensive, search algorithm, (b) an, efficient, but sub-optimal, greedy heuristic algorithm, and (c) an algorithm using simulated annealing to generate a feasible assignment of both priorities and preemption thresholds. Our ongoing work is evaluating the effectiveness of these algorithms. 2.3. Eliminating Unnecessary Preemptability While the above approach generates feasible scheduling attributes, it does not attempt to reduce unnecessary preemptability in the scheduling model. Reducing unnecessary preemptability is a key ingredient of our approach as will become clear in Section 3. Certainly, in the extreme case a task set may be schedulable under non-preemptive scheduling, and we can use that. In general, however, this will not be true, and we must chose preemption thresholds for tasks that are as high as possible, without sacrificing schedulability. We have developed an algorithm that does just that. The algorithm works by considering one task at a time, going from higher priority to lower priority. For each task considered, we assign the highest preemption threshold value that will still keep the task set schedulable. 3. Designing Scalable Multi-Tasking Implementations In this section we show how a design model consisting of a set of periodic and sporadic tasks can be efficiently implementing using a small number of event-handling tasks (Figure 1). A smaller number of tasks at implementation results in fewer preemptions and context switches 1. It also results in significant memory savings due to the need to have fewer stacks. We will assume that a design model consists of a set of periodic and sporadic tasks. Each such task is triggered 1 Note that within an event-handling task, the cost of switching from one event to the next is minimal, since there is no context to be saved.
by an event ( ), and executes an action ( ). We will ignore any dependencies between tasks. Our ongoing work is extending the approach to include various dependencies between tasks. At implementation we will use a set of event handling tasks. Each event is then mapped to one of the implementation tasks. At run time, the underlying executive uses this mapping to insert the event into its target task s event-queue from which the event gets processed by executing the action associated with it. Our strategy to map this design model into an implementation consists of the following steps: (1) First, we use the set of tasks in the design model and generate a feasible assignment of priorities and preemption thresholds. We then refine this assignment to eliminate any unnecessary preemptability, while still maintaining feasibility, as discussed in Section 2.3. (2) We then use this assignment of scheduling attributes to partition the tasks into the smallest number of nonpreemptive groups. This is discussed in Section 3.1. (3) Finally, we implement each non-preemptive group in an event-handling task. The priority of these eventhandling tasks is dynamically managed such that the schedulability equations of the implemented model is the same as that of the design model. This ensures that the implementation preserves schedulability. The dynamic priority management of event handling tasks is discussed in Section 3.2. 3.1. Partitioning Tasks into Non-Preemptive Groups We have already discussed how the use of preemption thresholds eliminates unnecessary preemptability. We now use this idea to form non-preemptive groups. A nonpreemptive group consists of a set of tasks in which every pair is mutually non-preemptive. By looking at the scheduling attributes of two tasks, we can identify whether one task can preempt the other. In this way, we can form pairs of tasks that are non-preemptive with respect to each other. These tasks can then be grouped into non-preemptive groups, where a non-preemptive group consists of a set of tasks in which every pair is mutually non-preemptive. In general, there may be many ways to merge tasks into non preemptive groups. We have developed an algorithm that takes a task set, along with their scheduling attributes, and partitions the task set into a minimum number of nonpreemptive groups. Each such non-preemptive group is then used as an event-handling task in the implementation. 3.2. Priority Management of Event Handling Tasks Each event handling task in the implementation potentially handles many events corresponding to multiple tasks in the design model. Each such event has a priority and a preemption threshold assigned to it. We want to ensure that the implementation preserves the schedulability. In other words, the scheduling of the implementation should be consistent with the preemption threshold scheduling model if each design level task was implemented as a separate task. In the implementation, we have two levels of scheduling. Within a single task, we have events processed in a non-preemptive manner based on event priority. This nonpreemptability of event processing within an implementation task is consistent with that of the design model since they are made up of a non-preemptive group. When there are multiple implementation tasks, tasks can preempt each other based on their priorities. The priority of a task is managed as follows. When an event is generated and deposited into the event queue of a task, the task s priority is set to the maximum of its current priority, and the priority of the event. When a task picks up an event to process, the priority of the task is set to the preemption threshold of the event. At the end of the event processing, its priority is set to the highest priority pending event in its event queue. With this scheme, a task s priority is (1) maximum of all the pending events in its event queue, when it is not processing an event, and (2) the preemption threshold of the event being processed when it is processing an event. It is easy to see that this priority scheme is consistent with the preemption threshold scheduling model. 4. Case Studies To illustrate the benefits of our approach we apply it to published case studies on the benefits of real-time schedulability analysis for real-time software design. The first example represents the Attitude and Orbital Control System for the Olympus Satellite, and we use the task set given in [2]. The second example is the task set describing a generic avionics platform (GAP) given in [10].
4.1. Olympus Satellite The task set consists of 21 tasks, and includes both periodic and sporadic tasks, although the distinction is not important in our discussion. Since no deadlines were given, we assume that the deadline equals period for each task. The task set is presented in Table 1, and has a utilization of. The task set is schedulable under preemptive scheduling, but not under non-preemptive scheduling. This is because some of the tasks, especially task 10, have a long execution time and if not preempted will cause missed deadlines for tasks with tighter deadlines (e.g., task 1 and 13). If we scale the computation times, we find that the breakdown utilization of this task set is with preemptive scheduling, but increases to when preemption thresholds are used. To generate an implementation, we first assigned the scheduling attributes to the task set, and then fine-tuned them to minimize preemptability. The resultant assignment is also shown in Table 1. We use higher numbers to denote higher priorities. As is clear from the table, many of the tasks are assigned a preemption threshold of 21, the highest priority, thus making all those tasks non-preemptable. In fact, only 3 tasks are not assigned a threshold of 21; these tasks have large computation times and therefore must be preempted to ensure schedulability. In this way, we can see that the assignment of scheduling attributes automatically finds the necessary preempt ability within tasks. This assignment can then be used to form non-preemptive groups. This results in three groups: (a) task 10, (b) tasks 8 and 12, and (c) all other tasks. Thus, the entire system can be implemented with only 3 tasks. 4.2. Generic Avionics Platform The avionics task set consists of 17 tasks, and includes both periodic and sporadic tasks. Again the distinction is not important in our discussion. The deadline equals period for each task in this case. The task set is presented in Table 4.2, and has a utilization of. The task set is schedulable under both preemptive and non-preemptive scheduling. If we scale the computation times, we find that the breakdown utilization of this task set is with preemptive scheduling, and with non-preemptive scheduling. Also, there is no schedulability improvement using preemption thresholds. Task Period WCET Priority Threshold 1 100 4.08 20 21 2 1000 2.06 11 21 3 500 4.12 18 21 4 2000 8.25 4 21 5 625 2.06 16 21 6 1870 2.06 5 21 7 1000 2.06 12 21 8 10000 99.32 2 19 9 2000 45.82 6 21 10 2000 425.82 7 10 11 10000 58.52 3 21 12 1000 83.02 13 19 13 100 24.62 21 21 14 1000 63.7 14 21 15 500 5.32 19 21 16 2000 32.02 8 21 17 1000 22.52 15 21 18 2000 32.02 9 21 19 1870 51.5 10 21 20 625 49.8 17 21 21 36000 9.42 1 21 Table 1. Task Set for Olympus Satellite System We again used the same approach of reducing preemptability and then finding the tasks for implementation. For the task set above, we find that the task set is schedulable under non-preemptive scheduling with the preemption threshold set to the highest priority. Thus, the system can be implemented with only a single task. If we scale the utilization to, where it is not schedulable with nonpreemptive scheduling, we find that the system requires 3 tasks for implementation. 5. Conclusion We have described current results from our research into automatic synthesis of multi-tasking implementations from real-time design models. Our approach is based on a new scheduling model using preemption thresholds for tasks that integrates and subsumes both preemptive and non-preemptive scheduling models. As a result it provides higher schedulability than both preemptive and non-
Task Period WCET Priority Threshold 1 25 2 16 17 2 25 5 17 17 3 40 1 15 17 4 50 3 13 17 5 50 5 14 17 6 59 8 12 17 7 80 9 10 17 8 80 2 11 17 9 100 5 8 17 10 200 3 3 17 11 200 1 4 17 12 200 1 5 17 13 200 3 6 17 14 200 1 7 17 15 200 3 8 17 16 1000 1 1 17 17 1000 1 2 17 Table 2. Task Set for Generic Avionics Platform preemptive scheduling models. Using this new scheduling model we are able to assess schedulability at design time. The assessment of schedulability includes finding a set of feasible scheduling attributes for tasks. We can then refine a set of feasible scheduling attributes to eliminate any unnecessary preemptions. To reduce run-time multi-tasking costs, we can combine several design level tasks into a single implementation task. This is done in a way that preserves the schedulability assessment at design time. Run-time multi-tasking costs are reduced by minimizing the number of implementation tasks. A fewer number of tasks in the implementation results in memory savings due to the stack space needed for each task. It also conserves CPU bandwidth due to reduced preemptions and context switches. Our ongoing research work is integrating the approach described in this paper with object-oriented design and automatic synthesis of implementations from object-oriented design models [11]. In conjunction with automatic code generation from design models [7], we believe that our approach takes a significant step towards streamlining realtime software design, and eliminating many of the ad-hoc and manual steps needed in current practice to develop a schedulable real-time system. References [1] M. Awad, J. kuusela, and J. Ziegler. Object-Oriented Technology for Real-Time Systems: A Practical Approach using OMT and Fusion. Prentice Hall, 1996. [2] C. M. Bailey, A. Burns, A. J. Wellings, and C. H. Forsyth. A performance analysis of a hard real-time system. Technical Report YCS 224, Department of Computer Science, University of York, 1994. [3] A. Burns and A. J. Wellings. HRT-HOOD: A Design Method for Hard Real-Time. Real-Time Systems, 6(1):73 114, 1994. [4] B. P. Douglass. Doing Hard Time: Developing Real-Time Systems with Objects, frameworks, and Patterns. Addison- Wesley, 1999. [5] L. George, N. Rivierre, and M. Spuri. Preemptive and nonpreemptive real-time uni-processor scheduling. Technical Report 2966, INRIA, France, sep 1996. [6] H. Gomaa. Software Design Methods for Concurrent and Real-Time Systems. Addison-Wesley Publishing Company, 1993. [7] P. Karvelas. Schedulability Analysis and Automated Implementation of Real-Time Object-Oriented Design Models. Master s thesis, Concordia University, May 2000. [8] M. H. Klein, T. Ralya, B. Pollak, R. Obenza, and M. G. Harbour. A Practitioner s Handbook for Real-Time Analysis. Kluwer Academic Publishers, 1993. [9] C. Locke. Software architecture for hard real-time applications: Cyclic executives vs. fixed priority executives. The Journal of Real-Time Systems, 4(1):37 53, Mar. 1992. [10] C. Locke, D. Vogel, and T. Mesler. Building a predictable avionics platform in ada: A case study. In Proceedings of IEEE Real-Time Systems Symposium, pages 181 189. IEEE Computer Society Press, Dec. 1991. [11] M. Saksena, P. Karvelas, and Y. Wang. Automatic synthesis of multi-tasking implementations from real-time objectoriented models. In Proceedings, IEEE International Symposium on Object-Oriented Real-Time Distributed Computing, March 2000. [12] B. Selic, G. Gullekson, and P. T. Ward. Real-Time Object- Oriented Modeling. John Wiley and Sons, 1994. [13] S. A. Stolper. Streamlined design approach lands mars pathfinder. IEEE Software, September 1999. [14] K. Tindell, A. Burns, and A. Wellings. An extendible approach for analysing fixed priority hard real-time tasks. The Journal of Real-Time Systems, 6(2):133 152, Mar. 1994. [15] Y. Wang and M. Saksena. Fixed priority scheduling with preemption threshold. In Proceedings, IEEE International Conference on Real-Time Computing Systems and Applications, December 1999.