Extensions: context switching can be modelled as increased execution time. Preperiod deadlines can be handled with a modified utilization bound. Interrupts can be handled by analyzing the utilization of each task individually, and adding terms to account for possible preemption by other (higher priority) tasks.

Priority inversion can be caused by synchronization and mutual exclusion, non-preemptable code regions, and FIFO queues. Handled similar to interrupts, by adding a term to account for inversion. Synchronization protocols such as no preemption, priority inheritance, highest locker's priority, and priority ceiling can bound priority inversion. Aperiodic tasks can be handled with sporadic servers by modeling as periodic tasks, with a fixed execution budget C in replenishment interval T, and then assigning priorities.

The presentation finishes with an interesting case study. A six-event system that was not designed with RMS was analyzed with RMA. Net result: redesigned the schedule to be feasible, requiring 3 people 3 weeks of effort.

It isn't directly relevant to our problem because:

• it is aimed at passive object-based environments
• it allows threads to span processors
• it allows objects to move across processors

I'm not completely sure what they mean by event; I thought that event delivery is always asynchronous. The last paragraph of the Section 3 introduction confirms that. But in the introduction to Section 5, the authors say the are going to discuss ``synchronous and asynchronous delivery''. Does that really mean ``notification'', which is from the perspective of the object that initiates the event?

The lessons learned about using AIX for real-time applications suggest that it isn't a good a real-time platform as Solaris. In particular, it had to be restricted to having only one user (does AIX have a real-time scheduling class with higher priority than all others?). They also restricted the implementation of the application and transport protocols to a single user process, and used joint scheduling by the protocol stack (what does that mean?). They recognize that their scheduler implementation has major limitations, but it's not discussed further here (they reference Nahrstedt's PhD thesis).

• predictably fast response to urgent events
• high degree of schedulability, which is the maximum degree of resource utilization at which task timing requirements can be met
• stability under transient overload: the ability to guarantee the deadlines of selected tasks

A less pessimistic test is based on the critical zone theorem:
Theorem 2: For a set of independent periodic tasks, if each task meets its first deadline when all tasks are started at the same time, then the deadlines will always be met for any combination of start times.

If a critical task is excluded from the schedulable set, it might be possible to include it by using period transformation. The period of the task is reduced, so that it only performs part of its processing in each smaller period. This could allow its priority to be raised.

Next, scheduling of both aperiodic and periodic tasks is considered. If an aperiodic task can preempt a periodic task, then it's response time can typically be drastically reduced. Sporadic servers service aperiodic events but can be scheduled usings Theorems 1 and 2, because they are viewed as periodic tasks that perform polling.

Priority inversion, in which a high priority task is delayed by a lower priority task, can occur when the high priority task is blocked by another. The priority ceiling protocol, in which a low priority task inherits the priorities of higher tasks when executing, can help alleviate this problem.

Guidelines for programming real-time systems in Ada in order to support rate monotonic analysis are presented. They include sharing data between periodic tasks using a monitor, rather than calling each other directly. Most of the remainder of the guidelines have to do with priorities.

The paper does not discuss the application-specific aspects of mode changes, such as deciding the task changes and the order in which they should be implemented. And the really hard issues, like deciding what each task should do when the ``global'' mode changes.

The authors address over-preemption with a preemption control protocol. It includes phase control and rate control. The authors discusses analysis of systems that weren't designed to support GRMS. They quantify the effect on schedulability of limiting the granularity of priority. There are several detailed examples, I didn't go through them yet.

The mechanisms are policy-independent, and have been incorporated into the Chimera RTOS. The overhead per rescheduler operation on a 25 MHz MC68030 is less than 1 microsecond.

This approach is most useful in hard-real time systems that need to handle thread overrun. The authors discuss some applications to soft real-time systems, using an application-specific policy such as ``borrowing'' execution time from the threads next execution cycle. Imprecise computations and adaptive (dynamic) real-time scheduling can be readily handled with this approach as well.

Discusses the US Navy NRaD/University of Rhode Island (URI) RT CORBA system, which supports expression and enforcement of end-to-end timing constraints. Timing constraints are supported through timed distributed method invocations ({\tt TDMI}s); a {\tt TDMI} corresponds to TAO's {\tt RT\_Operation}; an {\tt RT\_Environment} structure contains QoS parameters similar to those in TAO's {\tt RT\_Info}. One difference between the two approaches is that {\tt TDMI}s express required timing constraints, {\em e.g.}, deadlines relative to the current time, while {\tt RT\_Operation}s publish their resource, {\em e.g.}, CPU time, requirements. The difference in approaches may reflect the different time scales, seconds versus milliseconds, respectively, and scheduling requirements, dynamic versus static, of the initial application targets. However, the approaches should be equivalent with respect to system schedulability and analysis. In addition, NRaD/URI supply a new CORBA Global Priority Service, analogous to TAO's Scheduling Service, and augment the CORBA Concurrency and Event Services. The initial implementation uses {\em earliest-deadline-first within importance level} dynamic, on-line scheduling, supported by global priorities. A global priority is associated with each {\tt TDMI}, and all processing associated with that TDMI inherits that priority. In contrast, TAO's scheduling is initially static and off-line, and uses importance as a ``tie-breaker'' following the analysis of other requirements such as data dependencies. Both NRaD/URI and TAO readily support changing scheduling policy by encapsulating it in their respective CORBA Global Priority and Scheduling Services.