Integrating Real-Time Synchronization Schemes into Preemption Threshold Scheduling

Transcription

1 Integrating Real-Time Synchronization Schemes into Preemption Threshold Scheduling Saehwa Kim, Seongsoo Hong and Tae-Hyung Kim {ksaehwa, Abstract Preemption threshold scheduling (PTS) provides prominent benefits for fixed priority scheduling such as increased schedulability, reduced context switches, and decreased memory requirements. Since such benefits allow for scalable real-time system design, we have adopted it into our automatic implementation synthesis method for real-time object-oriented models. In this paper, we present the integration of real-time synchronization schemes into PTS. Specifically, we investigate how to integrate priority inheritance protocols into preemption threshold scheduling such as the basic priority inheritance protocol and the priority ceiling protocol. In our integrated schemes, (1) the preemption threshold, instead of the priority, of a bed task is inherited when bing occurs; and (2) priority ceiling, instead of preemption threshold ceiling is used. We also show that our integrated schemes can minimize worst-case context switches and thus is appropriate for the implementation of real-time object-oriented design models. 1. Introduction Priority-driven and preemptive scheduling has been a pivotal basis in most real-time application development since it has been introduced in the Liu and Layland's pioneering paper [1]. In the early stages of real-time systems research, many researchers have attached importance to early consideration of timing issues at design time using a set of derived tasks. With the maturity of schedulability analysis techniques [1, 9, 10], performing timing analysis in order to develop The work reported in this paper is supported in part by MOST under the National Research Laboratory (NRL) grant 2000-N-NL-01-C-136 and by the Korea Science and Engineering Foundation (KOSEF) grant R School of Electrical Engineering and Computer Science, Seoul National University, Seoul , Korea. Department of Computer Science and Engineering, Hanyang University, Ansan, Kyunggi-Do , Korea. schedulable real-time control applications has been quite successful.. The increased complexity of such applications requires the use of systematic software design methodologies and CASE tools as well. Thus, the two primary research thrusts in real-time systems are how to improve the schedulability by devising elaborate scheduling methods, and how to integrate schedulability analysis techniques to modern software engineering design methodologies. However, an evident dilemma in preemptive scheduling is that it may incur excessive context switching overhead at run-time. In fine-grain or mediumgrain thread-based processing, which is often the case in most thread-based real-time computing environments, the context-switching overhead may outweigh the benefits of multi-threading and preemptive scheduling. To alleviate the possible excessive run-time costs, Lamie at Express Logic, Inc. introduced the notion of preemption threshold [8]. It helps improve system responsiveness and throughput in fixed-priority preemptive scheduling based systems. The preemption threshold plays a parametric role that controls the degree of preemptiveness in fixed-priority scheduling. If the threshold of each task is same as the original priority, then it is equivalent to the preemptive scheduling. If each task has the highest threshold value in a system, then it degenerates to non-preemptive scheduling. As Wang and Saksena discussed in [1], the schedulability of a task set under preemptive scheduling does not imply that the same task set is also schedulable under non-preemptive scheduling and vice versa. They illustrated an example where a task set is not schedulable under either fixed-priority preemptive scheduling or nonpreemptive scheduling, but schedulable under preemption threshold scheduling. Thus, preemption threshold scheduling (PTS) is a good complement to fixed-priority preemptive scheduling. It improves schedulability, withholds unnecessary preemptions, reduces the number of tasks because a group of non-preemptive tasks can be regarded as a unit, and eventually helps allow scalable real-time system design. Meanwhile, there have been several research activities based on ROOM (Real-time Object-Oriented Modeling)

2 language [11, 12, 14], as recent efforts to integrate schedulability analysis techniques into object-oriented design methodology. This approach aims at providing programmers with a schedulability analysis capability for the automated implementation of ROOM-based designs. While such an approach is a help for designing a real-time model with timing analysis features, still it is hard to derive tasks from a given object model, for the lack of such an automated process in the design cycle. When a real-time system is viewed as a collection of concurrent objects that cooperate with each other in accomplishing system functionality, each object participates in multiple system functions. Thus, each object is subject to multiple timing constraints. In this sense, there are two extremes in mapping objects to tasks. One is to map each object to a single task, and the other is to map entire (multiple) objects to a single task (in order to reduce multi-tasking costs). Both implementation models are inadequate since they are not analyzable by the fixed-priority scheduling theory. To cope with this problem, Saksena and Wang in [3] suggests a method for multi-task implementation in that preemption threshold scheduling was used to reduce run-time multi-tasking overheads by exploiting non-preemptability as much as possible. This was based on their earlier work that investigated the schedulability analysis problem of preemption threshold scheduling [1]. In our previous work, we presented a systematic schedulability-aware method that can automatically generate a multi-threaded implementation from a given object-oriented design mode for a real-time system [4, 5]. We do not try to evade the problem of inter-object and intra-object concurrency control. Our method is a threestep process: (1) deriving scenarios (end-to-end computation units), (2) identifying logical threads, and then (3) deriving physical threads. Logical threads are mapped from mutually exclusive scenarios, and assigned priorities and preemption thresholds that can guarantee schedulability. To reduce the number of tasks, derived logical threads are partitioned into mutually exclusive groups of non-preemptive tasks. A group of nonpreemptive logical threads becomes a physical thread. As a result, a logical thread contains several mutually exclusive tasks and thus possesses as many scheduling attributes. This makes the traditional schedulability analysis impossible to use. The schedulability analysis of preemption threshold scheduling was conducted in [1]. However, real-time synchronization has not been considered in the work, though it is essential for implementing a real-time object-oriented model. Also, the priority inversion problem should be addressed in this discussion. In this paper, we consider the problem of integrating real-time synchronization schemes into preemption threshold scheduling. A direct use of conventional synchronization primitives may result in a priority inversion problem. Therefore, we investigate schedulability analyses for preemption threshold scheduling with the following two representative priority inheritance protocols: the basic priority inheritance protocol (BPI) in [6] and the priority ceiling protocol (PCP) in [6]. The remainder of the paper is organized as follows. Section 2 describes the task model with definitions for the discussion. In Sections 3 and 4, we present how to integrate the two priority inheritance protocols BPI and PCP into the preemption threshold scheduling. We conclude this paper in Section Task Model We use the same task model used in [1, 3, 6]. A uniprocessor environment is assumed and only properly nested mutexes are allowed. A system has a fixed set of tasks, each of which has a fixed period, known worst-case execution time, fixed priority, and preemption threshold. The bigger the value is, the higher the priority is it is conforms to the intuitive meaning of being a higher threshold. Table 1 summarizes the notations and descriptions, which will be used throughout the remainder of the paper. Table 1. Summary of notations for the underlying task model. Notation τ i T i C i π i γ i p i M i P(M i ), V(M i ) ϕ(m i ) Description A task The period of task τ i The worst-case execution time of task τ i The fixed-priority of task τ i The preemption threshold of task τ i The effective priority of task τ i A mutex (binary semaphore) Indivisible, un operation of mutex M i The ceiling of mutex M i

3 (π, γ) τ 3 ={ P( ), V( ), ={ P( ), P( ), V( ), V( ), ={ P( ), V( ), (6, *) τ 4 (5, 7) τ 3 try to (attempt to ) bed by transitive bing (3, *) τ 3 preempt (attempt to ) bed by un (, 2) inherit γ 3 un un t 1 t 2 t 3 t 4 t 5 t 6 Figure 1. An example that prevents uncontrolled bing. Under PTS, each task has a preemption threshold in addition to its regular priority. It is meaningful to assign each task a preemption threshold, which is no less than its regular priority. This prevents preemption unless the preempting task is higher than its threshold value. Since the priority of a task is dynamically changed at run-time through PTS and also through the use of synchronization schemes, we introduce the notion of effective priority. The effective priority of a task is the practical priority seen by the kernel scheduler. The scheduler of our system always schedules the task with the highest effective priority. The effective priority is defined as the original priority of the task when a task is released and until it gets the CPU (case 1). Once a released task gets the CPU (case 2), whether it is running, preempted, or bed, the effective priority is determined to be its preemption threshold or the highest effective priority of the tasks that is being bed by this task, whichever is highest. In summary, the effective priority is determined by the following rules. Note that the definition is given recursively. Effective priority of τ i Case 1. p i = π i Case 2. p i = max(γ i,, p 1, p 2,, p j ) where τ i is bing τ j. In traditional priority-based preemptive scheduling, tasks may experience bing due to synchronization. Under PTS, tasks may encounter another type of bing which we name PTS bing. Task τ i is said to be in PTS bing if it is bed by a lower priority task whose preemption threshold is higher than π i. t 1 t 2 t 3 t 4 t 5 t 6 t 7 t 8 Figure 2. A situation of transitive bing. 3. Preventing Uncontrolled Bing Without using priority inheritance protocols, the catastrophic priority inversion problem cannot be rectified in a real-time system that uses synchronization primitives. If there is an uncontrolled bing, the duration of bing cannot be predictable. BPI prevents the preemption that eventually causes a priority inversion by having the bing task inherit the priority of the bed task. The uncontrolled bing in traditional priority-based scheduling occurs when a medium priority task preempts a lower priority task that bs a higher priority task. Under PTS, we reformulate the original problem into the effective priority inversion problem by substituting a priority of a task with its effective priority. The rationale behind this formulation is obvious since an effective priority takes the place of a priority under PTS. In this formulation, given that task τ i is bed by τ L, priority inversion occurs (1) when a medium priority task τ M with γ L < π M < π i preempts τ L ; or (2) when another task τ H with π i < π H γ i preempts τ L. In summary, we give a definition for uncontrolled bing under PTS. Uncontrolled bing under PTS Suppose τ i is bed by τ j since τ j is in a critical section. If τ j is preempted by another task τ k where γ j π k γ i, it is called an uncontrolled bing under PTS.

4 τ 3 ={ P( ), V( ), P( ), V( ), ={ P( ), V( ), ={ P( ), V( ), (attempt to ) (attempt to ) un un ={ P( ), P( ), V( ), V( ), ={ P( ),, P( ), V( ), V( ), preempt 1 τ bed by 1 τ (try to ) τ 3 preempt un (try to ) bed by un dead! t 1 t 2 t 3 t 4 t 5 t 1 t 2 t 3 t 4 t 5 t 6 t 7 t 8 t 9 t 10 Figure 3. A situation of chained bing. We also define BPI under PTS as follows. Inheritance of effective priorities. When task τ H is bed by task τ L with π H > γ L, task τ L inherits p H from task τ H. Recovery of effective priorities. When task τ L exits from a critical section, task τ L recovers p L that it had before entering that critical section. It can be shown that this definition of BPI under PTS prevents preemptions that eventually cause priority inversion. Figure 1 shows such an example that follows our definition of BPI under PTS. Tasks and τ 4 do not preempt, so the uncontrolled bing is prevented. BPI under PTS bears similar properties with the original BPI in [6]. In the original protocol, a task can be bed in one of three forms of bing: (1) direct bing, (2) push-through bing, and (3) transitive bing. In our protocol, a task can be bed additionally in PTS bing. Direct bing occurs when a higher priority task attempts to a mutex ed by a lower priority task. It is to ensure the consistency of a non-preemptive shared resource. Pushthrough bing occurs under PTS when a medium priority task attempts to preempt a lower priority task that is bing a higher priority task, as described below. Figure 4. A situation of dead. In Figure 1, tasks and τ 4 are bed during the period of (t 4, t 5 ) and (t 5, t 6 ), respectively, in the pushthrough bings under PTS. Transitive bing occurs when task τ 3 is bed by, which in turn is bed by another task. Figure 2 shows an example for transitive bing. During the period of (t 6, t 7 ), is bed by while bing τ H. Therefore, τ H is indirectly bed by in a transitive manner. As such, transitive bing occurs when mutexes are accessed in a nested fashion. Additionally, a task can encounter chained bing. Chained bing (or a chain of bing) is said to occur if a task is repeatedly bed when it enters its critical sections. An example for chained bing is illustrated in Figure 3 where task τ 3 is bed during the period of (t 6, t 7 ) and bed again during (t 9, t 10 ). Note that chained bing is not a form of bing, but refers to a situation where a task is bed more than once. Note that the BPI protocol alone does not prevent dead. Dead may occur when multiple tasks try to access nested mutexes in a circular manner. Figure 4 shows an example for dead. In this example, both tasks τ H and τ L need to acquire two mutexes and. As shown, τ L waits for τ H to release, and τ H waits for τ L to release, while τ L and τ H are holding and, respectively. Therefore, a dead occurs at time t 5. Push-through bing under PTS Suppose that τ i, τ j, and τ k are three tasks with π i π j π k. Task τ i is bed by τ k, since τ k s mutex M i that τ i attempts to. If the effective priority of τ k is determined by inheriting π i, τ j cannot preempt τ k, because γ k π j. This is called a push-through bing under PTS. 4. Preventing Dead and Possible Long Bing Delay Although BPI prevents uncontrolled bing by means of push-through bing, it may incur dead and excessively long bing delay. Excessively long bing delay is frequent especially if there are transitive

5 and chained bings that involve in multiple synchronizations. If we intend to integrate BPI to the preemption threshold scheduling, the dead should be handled properly. In the original BPI, the priority ceiling protocol (PCP) is introduced to this end [6]. In this section, we present how PCP can be integrated into PTS, in order to prevent dead and possible long bing delay. The following condition is given as a sufficient one that guarantees the prevention of dead, transitive bing, and chained bing in a system. We also describe a synchronization scheme that satisfies this condition, in order to run the priority ceiling protocol under PTS. Condition 4.1. There is at most one and only task that acquires some mutexes that are also requested by another task τ i with π i > π c where τ c is the current running task. With this, whenever a task s, it sees at most one lower priority task that has acquired mutexes it may use. We can also easily see that it is guaranteed for a task to be bed (to acquire its mutexes) at most once and by at most one lower priority task. Now we prove that satisfying Condition 4.1 in BPI solves all the abovementioned problems of the original BPI. Theorem 1. Satisfying Condition 4.1 guarantees the prevention of dead, transitive bing, and chained bing. Proof. We prove it in the following three prevention cases of dead, transitive bing, and chained bing, respectively. Case 1. Proof of preventing dead Suppose there is a dead between two tasks and. Suppose both tasks need to acquire two mutexes and. As shown in Figure 4, waits for to release, and waits for to release, while and have acquired and, respectively. If the situation is allowed, a dead occurs at time t 5. However, cannot at t 3, because has already acquired a mutex that may be used by. In this case, should be bed at t 3, instead of being allowed to, mandated by Condition 4.1. Therefore, the dead is prevented. Case 2. Proof of preventing transitive bing Suppose that there is a transitive bing among three tasks of,, and τ 3 in an ascending order of priority. In other words, τ 3 is bed by, which in turn bed by. To make this happen, holds a mutex and runs, and then s and preempts as shown in Figure 2. However, when tries to its mutex, it will be bed since has already ed mutex that may be used by τ 3. This is a contradiction. Therefore, transitive bing cannot occur. Case 3. Proof of preventing chained bing Suppose there is a chain of bings among three tasks of,, and τ 3 in an ascending order of priority. Consider the possible bing chain shown in Figure 3. At time t 8 task τ 3 is bed again. However, cannot mutex at t 3, since has ed that is also requested by τ 3, according to Condition 4.1. Therefore, no chain of bing is allowed. In order to satisfy Condition 4.1, the original priority ceiling protocol (PCP) uses the notion of priority ceiling, associated with mutexes. It is defined as follows. The priority ceiling of mutex M i equals to max{π j τ j Ψ i } where Ψ i is a set of tasks that may use mutex M i. It is to guarantee for a task to get bed once for all and only when it tries to enter its critical section within its busy period for the first time. PCP in fully preemptive fixed-priority scheduling can be described by combining offline ceiling protocol and online ing protocol in a similar manner as in [7]. Ceiling protocol Each mutex M i is assigned to have a ceiling whose value is given by ϕ(m i ) = max{π j τ j Ψ i } where Ψ i is a set of tasks that may use mutex M i. Locking protocol LP1. A system ceiling, which is a system-wide scheduling attribute, is dynamically set to the maximum of priority ceilings of all mutexes being ed in the system. LP2. In order for task τ i to enter its critical section, π i should be higher than the system ceiling. LP3. If there is bing, BPI is applied Priority Ceiling vs. Preemption Threshold Ceiling In this section, we investigate the behavior of PCP when it is integrated into PTS (PCP under PTS). Among three ing protocols shown just before, LP3 is a mere adoption of BPI. So, BPI under PTS in the previous section can be used, eventually for preventing uncontrolled bing. LP1 is orthogonal to a specific

6 scheduling policy. Thus, only the LP2 needs to be redefined for PCP under PTS. Since each task has an additional scheduling attribute of preemption threshold under PTS, we should have priority ceiling and preemption threshold ceiling, respectively. The definition of priority ceiling is given in the previous section. The preemption threshold ceiling of a mutex is defined similarly as follows. The use of preemption threshold ceiling gives the same result since the highest preemption threshold ceiling will be assigned to those mutexes according to LP2, i.e. ϕ( ) and ϕ( ) are γ 3, which is greater than γ 1 and γ 2. τ 3 τ ={ 3 ={ P(M P( ), 1 ), V(M V( ), 1 ), P(M P( ), 2 ), V(M V( ), 2 ), τ ={ 2 ={ P(M P( ), 2 ), V(M V( ), 2 ), τ ={ 1 ={ P(M P( ) 1 ),, V(M V( ), 1 ), The preemption threshold ceiling of mutex M i equals to max{γ j τ j Ψ i } where Ψ i is a set of tasks that may use mutex M i. τ 3 γ 1 γ < 1 < π 2 π 2 γ 2 γ < 2 < π 3 π 3 With this, what to determine is which of the priority ceilings and preemption threshold ceilings to use for PTS. Under PTS, the number of tasks that can preempt the currently running task is decreased as compared to the original fully preemptive fixed-priority scheduling. Since just the condition for preemption is more restrictive under PTS than in the original fully preemptive scheduling, we can easily deduce the direct application of PCP, and thus adoption of priority ceilings would satisfy Condition 4.1. The effect of adopting preemption threshold ceiling (instead of priority ceiling) is confined merely to task preemptions. Note that the reason for using threshold value is to control the degree of preemptiveness. The use of preemption threshold ceiling merely fortifies the condition for allowing ing mutexes. Note that the preemption threshold is usually higher than its regular priority. We now present the given semantics of the priority ceiling and the preemption threshold ceiling makes PCP under PTS satisfy Condition 4.1. The condition cannot be violated either by use of priority ceiling or by use of preemption threshold ceiling. Suppose that Condition 4.1 is not satisfied by use of priority ceiling. That means that there are more than two tasks that hold some mutexes that are requested by tasks of higher priority than the current running task τ c. The simplest form of this case may occur if there are three tasks,, τ 3 in an ascending order of priority. Specifically, let tasks and hold mutexes and that may be requested by task τ 3 in violation of Condition 4.1. See Figure 5 that illustrates the situation. Task was preempted with ing mutex by. Task was also preempted with ing by τ 3. However, according to the use of priority ceiling, cannot acquire according to LP2, since the system ceiling (at point t 3 in Figure 5) is π 3 according to LP1. Therefore, it is impossible for to. Therefore, it is impossible for to. This shows the case that the use of priority ceiling in PCP under PTS can satisfy Condition PCP under PTS t 1 t 2 t 3 t 4 Figure 5. Impossible case that violates Condition 4.1 In Section 4.1, PCP under PTS is described in two versions: one that uses a priority ceiling, and one that uses a preemption threshold ceiling. We compare both versions with each other to determine which version is superior to the other. We will show that PCP with priority ceilings yields the smaller number of context switches and shorter response times of higher priority tasks than that with preemption threshold ceilings. The preemption threshold is usually assigned to have a value that represents higher than its regular priority, intended for minimizing unnecessary context switches. In [3], the maximum preemption threshold assignment algorithm is introduced, that is to use a higher threshold as far as the entire system remains schedulable. As a result, the priority ceiling cannot be higher than the preemption threshold ceiling in a task set. This is a reasonable heuristic to prevent unnecessary preemptions in fixedpriority scheduling without having to consider real-time synchronization schemes. Unfortunately, this is not always the case, here we will see an example where the context-switching overhead is rather aggravated and unnecessary bings occur if the preemption threshold ceiling is used instead of the priority ceiling for PCP under PTS.

7 τ 3 = {P( ), V( ), = {P( ), V( ), = {P( ), V( ), (π, γ) (4, 10) τ 3 complete (π, γ) (4, 10) τ 3 try to unnecessary bing (3, 10) (1, 2) un complete (3, 10) (1, 2) un M1 complete t 1 t 2 t 3 t 4 t 5 t 6 t 7 Figure 6. Example: PCP under PTS using priority ceiling. Suppose there are three tasks,, and τ 3 in an ascending order of priority. In Figure 6, task acquires at t 1, τ 3 s at t 2, preempts, and tries to acquire. If we adopt the use of priority ceilings, the system ceiling value for is 3. Be aware that only and may use as shown in the upper part of the figure. Since π 3 (= 4) is greater than the system ceiling (= 3), τ 3 succeeds to acquire and runs to completion at t 5. If we decide to use the preemption threshold ceiling method instead, the system ceiling value for is 10. See Figure 7 for the case. Since γ 3 (the preemption threshold for τ 3 ) is not greater than the system ceiling (in fact, they are equal), the task fails to acquire at t 3, thus gets bed due to synchronization. Now the preempted task resumes, and τ 3 remains bed until releases. Consequently, τ 3 is bed unnecessary between t 3 and t 4, and two more unnecessary context switches are incurred. This kind of ceiling bing is likely to be frequent in practice. Remember that the preemption threshold tends to have the largest value possible. The preemption anomaly is largely owing to the very maximum preemption threshold assignment policy. Consequently, there can be too many thresholds reaching the highest value in a system, which makes the ceiling bing react poorly to synchronizations. From the example above, we have shown that PCP with priority ceilings (PCP-Type 1) performs better than PCP with preemption threshold ceilings (PCP-Type 2) with respect to run-time costs and the response times of higher priority tasks. The latter may incur unnecessary bing and thus unnecessary context switches. When current running task τ i tries to enter its critical section under PTS, there is a case where τ H is not bed in PCP-Type 1 but bed unnecessarily only in PCP-Type 2: it happens if the preempted task τ L with γ L < t 1 t 2 t 3 t 4 t 5 t 6 t 7 Figure 7. Example: PCP under PTS using preemption threshold ceiling. π H has acquired mutex M l, which may be requested by τ l with π l < π H and γ l γ H. This type of ceiling bing does not contribute to the prevention of dead and long bing delay since it is due to ed mutexes that may be requested by lower priority tasks. For every such case, there are two additional context switches in PCP-Type 1 as compared with in PCP-Type 2. Moreover, this unnecessary bing increases the response time of the bed higher priority task. Note that such case tends to be very frequent due to maximum preemption threshold assignment policy under PTS. Based on these observations, PCP under PTS protocol is completely described as follows. Ceiling protocol Each mutex M i is assigned to have a priority ceiling whose value is given by ϕ(m i ) = max{π j τ j Ψ i } where Ψ i is a set of tasks that may use mutex M i. Locking protocol nlp1. A system ceiling, which is a system-wide scheduling attribute, is dynamically set to the maximum of priority ceilings of all mutexes being ed in the system. nlp2. In order for τ i to enter its critical section, π i should be higher than the system ceiling. nlp3. Inheriting effective priorities If high priority task τ H is bed by low priority task τ L with π H > γ L, task τ L inherits p H from task τ H as its effective priority. nlp4. Recovering effective priorities When task τ L exits from a critical section, task τ L recovers the p L that it had before entering that critical section.

8 In this new ing protocol for PCP under PTS, two things are noteworthy. The effective priority is used for priority inheritance like BPI under PTS. One the other hand, the priority ceiling instead of preemption threshold ceiling is used for dead-free synchronization. 5. Conclusions We have presented real-time synchronization schemes for preemption threshold scheduling (PTS). In particular, we have investigated how to integrate priority inheritance protocols into preemption threshold scheduling such as the basic priority inheritance protocol and the priority ceiling protocol. Since each task has an additional scheduling attribute called a preemption threshold under PTS, it is not intuitive how to use existing schemes under PTS. We have presented the notion of the effective priority, which is conceptually, a task priority that is used by the kernel scheduler for selecting a task to be dispatched. With this, we have identified the uncontrolled bing under PTS and presented BPI under PTS that avoids uncontrolled bing. We have also presented a rule for preventing dead, transitive bing, and chained bing, which served as a guideline for designing PCP under PTS. We have shown that the adoption of priority ceilings instead of preemption threshold ceilings yields the smaller number of context switches and the shorter response times of higher priority tasks. Consequently, the integrated scheme, which minimizes worst-case context switches, is appropriate for the automated implementation of real-time object-oriented design models. References 1. C. Liu and J. Layland, Scheduling algorithm for multiprogramming in a hard real-time environment. In Journal of the ACM, vol. 20(1), pp , Jan M. Saksena and Y. Wang. Scalable real-time system design using preemption thresholds, In Proceedings of IEEE Real-Time Systems Symposium, pp , Y. Wang and M. Saksena. Scheduling fixed priority tasks with preemption threshold. In Proceedings of IEEE Real-Time Computing Systems and Applications Symposium, pp , S. Kim, S. Cho, and S. Hong. Schedulability-aware mapping of real-time object-oriented models to multithreaded implementations. In Proceedings of International Conference on Real-Time Computing Systems and Applications, pp. 7-14, S. Kim, S. Hong, and N. Chang, Scenario-based implementation architecture for real-time objectoriented models, In Proceedings of IEEE International Workshop on Object-oriented Real-time Dependable Systems, R. Rajkumar, L. Sha and J. Lehoczky. Priority inheritance protocols: an approach to real-time synchronization. In IEEE Transactions on Software Engineering, vol. 39, pp , M. Chen and K. Lin. Dynamic priority ceilings: A concurrency control protocol for real-time systems. In Real-Time Systems Journal, vol. 2, pp , W. Lamie, Preemption-Threshold, White Paper, Express Logic Inc., Available at 9. M. Harbour, M. Klein, and J. Lehoczky, Fixed Priority Scheduling of Periodic Tasks with Varying Execution Priority, In Proceedings of IEEE Real-Time Systems Symposium, pp , Dec J. Lehoczky, L. Sha, and Y. Ding, The Rate Monotonic Scheduling Algorithm: Exact Characterization and Average Case Behavior. In Proceedings of IEEE Real-Time Systems Symposium, pp , Dec M. Saksena, P. Freeman, and P. Rodziewicz, Guidelines for Automated Implementation of Executable Object Oriented Models for Real-Time Embedded Control Systems, In Proceedings of IEEE Real-Time Systems Symposium, pp , Dec M. Saksena, A. Ptak, P. Freeman, and P. Rodziewicz, Schedulability Analysis for Automated Implementations of Real-Time Object-Oriented Models, In Proceedings of IEEE Real-Time Systems Symposium, pp , Dec H. Gomma, Software Design Methods for Concurrent and Real-Time Systems, Addison-Wesley, B. Selic, G. Gullekson, and P. T. Ward, Real-Time Object-Oriented Modeling. John Wesley and Sons, 1994.