application or set of cooperating real-time applications. Many such approaches rely on total knowledge of the set of available resources and are often static in nature. Some, such as priority scheduling, rely on the decisions of human experts who must correctly assign relative priorities to all tasks in the system. Many even require programmers to estimate upper bounds for all execution paths and to pre-compute the resources necessary for correct execution. This paper describes ongoing investigations at Microsoft Research into algorithms for adaptive real-time scheduling and resource management. We are implementing a system which will allow sets of independently authored real-time applications to be scheduled, providing both initial resource negotiation and dynamic feedback to applications about their resource consumption. Instead of relying on human beings to precompute scheduling and resource requirements, applications will be able to dynamically adapt their run-time behavior to the resources available. Under overload conditions, user preferences and policies will be applied in order to bring the total resource requirements within available resources. This will permit chosen applications to continue executing perfectly even while others execute with dynamically renegotiated resource grants or are gracefully shut down, as per user preferences. We believe that this approach will lead to real-time scheduling and resource management algorithms which are appropriate for workstation and home multi-media environments. While such static, expert-intensive approaches to real-time resource allocation have a proven track record for programming embedded real-time control systems, they have a number of drawbacks that make them inappropriate for programming applications in more dynamic real-time environments such as multi-media workstations or home multi-media systems. In particular, the underlying assumptions that the available resources are fixed and known and that only a single application or set of cooperating applications are being run do not hold. In workstation or home multi-media environments, more than one real-time application may be executed simultaneously. These applications may be independent and may be independently authored. When digital home information systems are available, indeed, even individual applications may actually consist of independently authored and independently purchased components which may be composed to 1. The Need for Adaptive Real-Time Resource Management A number of methods have been developed that allow scheduling and resource allocation decisions to be made for a single real-time meet particular user requirements. For instance, video delivered on demand from a digital cable system might be passed through a third-party video filter module and then be displayed in a window in real-time by a rendering algorithm. Meanwhile, another video stream might also be being displayed in another window. Clearly, static scheduling approaches are inadequate for such environments. negotiations with individual applications in order to avoid system overload conditions. 3. Scheduling Details We have taken a hierarchical approach to the real-time scheduling and resource management problem. General high-level abstractions are used for reasoning about overall system and application behavior. Simple low-level abstractions are used for all frequently evaluated scheduling decisions. 2. Solution Overview 3.1 High-Level Reasoning A key to our approach to the adaptive realtime scheduling problem is combining initial estimates of resources required by each component of the applications with dynamic feedback as to the actual resources used by application components as they run. This feedback is then used to fine tune the resource estimates for subsequent executions of the same components, providing a basis for applications to adapt themselves to the actual resources available and for making accurate requests for resource grants. The following high-level abstractions are used by our approach to real-time scheduling and resource management: • Resources: Units used for reasoning about system behavior. Individual resources might include CPU cycles, I/O bus bandwidth, network packets, and devices such as video frame buffers and sound cards. Resource requirements are actually multi-valued sets of individual resource requirements. A second aspect of our approach is providing for dynamic inheritance of thread scheduling constraints across module and RPC boundaries. Scheduling constraints include such information as scheduling deadlines and importance values. This approach can be thought of as a generalization of classical priority inheritance algorithms[Sha et al. 90]. • Activities: Executable tasks, which may themselves consist of other activities. Example activities include playing a studioquality video stream, recording and transmitting video for a video-conferencing application, and recording voice input for a speech recognition system. Activities may span multiple address spaces and contain multiple threads of control. They provide high-level units of resource negotiation and allocation and are executed with rights granted by secured user credentials. Several activities may be concurrently executed on a single machine. Finally, the system includes the capability to reason about predicted application resource and scheduling requirements. These requirements are associated with application components, allowing total application resource requirements to be estimated, with the estimates being dynamically updated, and for resource negotiation to occur when an application is invoked or when available resources change. User policies and preferences are factored into resource negotiations, particularly when overload conditions are anticipated or occur. While an adaptive approach allows applications to scale themselves to limited resources when overload is detected, predicting and avoiding overload entirely is often preferable. High-level reasoning about system resource availability and application resource requirements is used to accomplish this goal, driving proactive resource • Goals: Declarations of requirements for correct execution of an activity. Goals are typically requirements for resources along with a timeliness requirement. Just as activities can be composed of sub-activities, goals can be decomposed into sub-goals. Example goals include displaying 30 video frames per second at a given resolution and jitter, reading one half megabyte of data from disk every second, and echoing input characters within 30 milliseconds. Goals are mapped to sets of low-level thread scheduling constraints that are provided to the scheduler during execution. 3.2 Low-Level Scheduling The goal of a scheduling algorithm is to maximize the total utility provided by the combination of activities executed by the system. In general, the utility functions for each potential activity to be scheduled can be extremely complex and non-obvious[Locke 86]. Also, while highlevel reasoning about scheduling and resource allocation can afford to be quite general and somewhat expensive since it occurs infrequently, low-level scheduling decisions happen extremely frequently, and so must be very simple. • Preferences: Input from the user as to the desired behavior of the system, and of particular applications. Preferences may be either retrieved from a database, or in extraordinary cases, obtained by directly querying the user. Example preferences include statements that a video-phone call should pause a movie unless it's being recorded and that video should be degraded before audio when in overload. These abstractions make it possible to reason about application and overall system behavior. For instance, by comparing the resources available to an activity to the resource requirements associated with the collection of goals for an activity, it is possible to predict whether or not the activity should be able to execute correctly given those resources. Should a desired activity not be able to be executed, a top-level management activity can then examine alternatives, consulting the user preferences in order to evaluate relative importance of the current activities, possibly leading to a renegotiation of the resources granted to some of them. Therefore, in order to both simplify low-level scheduling to a computationally efficient endeavor and to simplify the programmer's task, a standard family of simple approximations to the actual utility functions is used. Despite the possibility of over-simplification in some cases, Northcutt has shown that this family of utility functions can work well in practice[Northcutt et al. 90, Wall et al. 92]. Figure 3-1 presents a graph characterizing this family of utility functions.