WO2000050991A2

WO2000050991A2 - Method and apparatus for scheduling program code in a computer system

Info

Publication number: WO2000050991A2
Application number: PCT/IB2000/000081
Authority: WO
Inventors: Robert Kroeger; William Cowan
Original assignee: Liquimedia, Inc.
Priority date: 1999-02-26
Filing date: 2000-01-10
Publication date: 2000-08-31
Also published as: WO2000050991A3; AU3070300A

Abstract

Embodiments of the invention comprise a mechanism configured to schedule program code for execution and provide feedback regarding the schedule. Program code, or other unit of execution, is referred to herein as a performer. Each performer has associated information that includes historical information regarding its execution behavior which is used to predict the future behavior of the performer (e.g., mean and variance of the execution time, etc.). In one or more embodiments of the invention, one or more performers are scheduled for execution during an execution interval that is referred to as a basic execution period or basic period. A scheduler insures that the performers that are scheduled to execute during the basic period have at least a threshold probability (referred to as a safety factor (or Sf) of executing to completion during the basic period. If a schedule satisfies the safety factor it is considered to be correct. Where the schedule is not considered to be correct, one or more incorrect performers may be removed from the schedule and the schedule is re-verified. A conductor iterates through a verified schedule to invoke each performer if it believes that the performer can execute to completion during the basic period. During each basic period, the conductor gathers information associated with a performer's behavior that can be used to re-evaluate the correctness of a schedule. Through a continual process of regular re-verifications, the invention can provide probabilistic realtime execution of independently authored code fragments.

Description

METHOD AND APPARATUS FOR SCHEDULING PROGRAM CODE

IN A COMPUTER SYSTEM

BACKGROUND OF THE INVENTION

1. HELD OF THE INVENTION

This invention relates to scheduling program code in a computer system, and more particularly, to the use of a record of the program code's previous executions to schedule the program code and to perform admission control on other as yet unscheduled program code.

2. BACKGROUND ART

A computer system can execute several programs. The simplest way to do this is to execute one after another. However, it has become common place for a computer system to divide the execution of programs up into multiple short pieces or fragments of program code and then interleave the execution of these fragments of program code. If these code fragments are sufficiently short, then all the tasks will appear to be executing in parallel.

A program may require resources to execute - at a minimum it will need access to the computer system's memory and use of a processor. There could be more programs executing than resource providers exist. In this case, the computer system must provide a mechanism by which the interleaved fragments of program can share resource providers. This is the purpose of an operating system - to allocate resources to the fragments of programs such that the programs operate correctly and appear to each progress in parallel.

Many applications of computer systems require programs to operate in "realtime". This imposes an additional constraint on a program. Not only must it compute the correct result but it must compute it within a bounded amount of time. Typically, programs that need to respond immediately to human users or control physical processes must execute in realtime. For example, an air traffic control system that processes radar input to detect possible collisions and warn air traffic controllers or pilots in time to react, is a realtime program. Another example of a realtime program, is a multimedia application such as a game that delivers continuous streams of multimedia data (e.g., audio and video) to the user.

If the computer system is executing several realtime programs, it must, just as it would interleave fragments of non-realtime computation, break realtime programs up into code fragments whose execution it would then interleave. However, in this case, the mechanism for scheduling these various fragments must take into account the realtime deadlines of the various fragments. For example, in a multimedia application, a program generating a game's sound track must avoid breaking the continuity of the stream of audio samples forming the sound track. Consequently, an operating system capable of supporting this kind of computer program must enforce a resource sharing on all its running programs such that the sound- generating program receives any resources it needs so it can always generate additional sound track samples at the same rate as the music actually plays.

There are several ways to implement an operating system capable of providing a deadline-aware resource sharing mechanism. A "cyclic executive" is the simplest such mechanism but it achieves its simplicity at the price of inflexibility and additional development effort. Programmers must manually divide their realtime programs into fragments and verify by hand that every fragment satisfies its realtime constraints. Further, to add any new realtime code later, they must repeat this verification. Because any change in the realtime programs running on this kind of realtime operating system requires the assistance of the programmers, a cyclic executive can only provide "static" resource allocation.

Control applications such as one that operates an anti-lock braking system, where the task environment and range of possible computations are both highly constrained, can be effectively implemented on a cyclic executive.

However, this simple and reliable strategy is unsuited to the extremely variable computational environment of multimedia systems such as game consoles, set top boxes and personal computers.

The more flexible alternative to a cyclic executive is a realtime operating system capable of performing dynamic realtime resource allocation.

Purchased at the price of a much more complicated implementation, such a system supports modifying the set of executing realtime programs without halting the operating system.

The challenge and complexity of a dynamic realtime operating system has resulted in a number of commercial and academic developments in this area. Most of these developments (e.g., Realtime Mach, capacity reserves, proportional share, Solaris, Rialto, etc.) use threads and preemptive scheduling. The combination of threads and preemptive scheduling provide a mechanism for an operating system to start and stop many different software programs at arbitrary points in their execution and switch between them. This lets the operating system divide a set of running software programs into fragments and interleave their execution with minimal cooperation from the software program's authors.

However, for a dynamic realtime operating system to use this mechanism, it must compute an ordering of thread invocations in realtime that guarantees that all the realtime threads meet their deadlines. Computing this schedule dynamically involves theoretical latencies that are unbounded and practical latencies that are large and is the central implementational difficulty in building a dynamic realtime operating system.

Previously implemented dynamic realtime operating systems cannot allocate computational resources at a sufficiently small granularity because they allocate a processor's time with threads. Even on the fastest systems, switching between threads result in delays of several microseconds. This delay comes from two sources: the time needed to load and save thread state, and the time required to compute a candidate for the next to be executed thread. As a result, using the processor efficiently requires task durations of a millisecond or longer. Common tasks for a multimedia operating system such as synthesizing positionalized sound or animating sprites take far less than a millisecond for each invocation. Consequently, a multimedia operating system must provide an alternative to threads for the allocation of processor time.

The light weight fragments of execution found in a cyclic executive provide an alternative to threads. However, these fragments must be combined together manually by programmers. This is unacceptable for a multimedia operating system because it needs the capability of dynamically altering which code fragments it is executing. Maintaining realtime execution of these fragments requires that the operating system attempt to execute only code fragments that can complete their execution within a specified interval. It would be beneficial for a multimedia operating system (or other operating system to be able to determine the elapsed duration of a randomly selected group of realtime code fragments before actually executing them. SUMMARY OF THE INVENTION

Embodiments of the invention comprise a mechanism to schedule program code for execution and use feedback to dynamically refine this schedule. Program code, or other units of execution, is referred to herein as a performer. In an embodiment of the invention, a performer is an object- oriented object representing a need for a resource. In one or more embodiments of the invention, where the performer is a fragment of realtime computation, a computer operating system repeatedly invokes the performer at a fixed rate.

Embodiments of the invention may be used to provide admission control and resource allocation to program code. According to one or more embodiments of the invention, an admission control mechanism insures that program code that is scheduled for execution has time to execute. Resources such as processor time, bandwidth, memory, etc. may be allocated using one or more embodiments of the invention.

Each performer has associated information that includes a history of its execution behavior. The performer information is used to predict the future behavior of the performer in embodiments of the invention. A performer's information includes the amount of time (or other resource) that the performer has used in previous invocations, a count of the number of times the performer has been invoked and additional state.

In one or more embodiments of the invention, one or more performers are scheduled for execution during an execution interval that is referred to herein as a basic execution period or basic period. A basic period extends for a given amount of time some, or all of which is used to execute performers. In one or more embodiments of the invention, the basic period is repeated such that the same or other scheduled performers may be executed.

In one or more embodiments of the invention, a scheduler manages a schedule of performers. The scheduler uses a mechanism called a verifier to insure that the performers that are scheduled to execute during the basic period have at least some threshold probability (referred to as a safety factor, or Sf) of executing to completion during the basic period. The safety factor is a configurable value between zero and one hundred percent. The value chosen for the safety factor is dependent on the degree of certainty desired that the scheduled performers will complete during a basic period. For example, for a high degree of certainty, a value of 99.99% may be assigned to Sf. That is, a schedule is correct if the probability of all of the performers in the schedule executing to completion in a single basic period exceeds the safety factor.

The correctness of a schedule may be verified more than once. In one or more embodiments of the invention, the correctness of a schedule is verified prior to adopting it as the current schedule and invoking the performers within the schedule. A schedule may also be subsequently verified as additional behavioral information is collected for the scheduled performers. A schedule is verified whenever the schedule is modified (e.g., one or more performers are added or removed from the schedule, or the ordering of the scheduled performers is changed). Any performers comprising the schedule continue to execute during the verification process.

Where the schedule is not considered to be correct, one or more incorrect performers may be removed from the schedule. After the removal, the new schedule is re-verified. The process of removing incorrect performers and re-verifying the schedule may be repeated until a correct schedule is achieved or a determination is made that the schedule cannot be verified.

A conductor iterates through a schedule to invoke each performer in the schedule during the basic period. The conductor may, however, determine that a performer cannot complete in the time remaining in the basic period. In this case, the conductor skips the performer during that instance of the basic period. Whether or not the performer is executed, the conductor may update the performer's information to reflect the handling and execution of the performer during the basic period. The conductor may update a state associated with the performer. Where the conductor skips a performer, the conductor increments a "progress" value that reflects the number of basic periods of work that a performer would need to do to remain synchronized with the actual passage of time.

Embodiments of the invention offer a solution to difficulties involved in developing a schedule of threads (e.g., realtime threads). The invention is a version of dynamic allocation that retains the essence of the static cyclic executive, while taking advantage of the characteristics unique to multimedia. Further, unlike most existing dynamic realtime operating systems, the invention provides an admission control mechanism for controlling the addition of fragments of realtime program code to a schedule.

While discussed from the viewpoint of an embodiment of the invention that allocates processor cycles, embodiments of the invention may be extended to include other resources such as network bandwidth and input and output devices.

Instead of allocating computational resources at the thread level, embodiments of the invention allocate resources with a lightweight abstraction called a performer. Performers discard the overhead of context switching by abandoning preemption. They must yield the processor voluntarily. Programmers statically divided an application into groups of performers to reduce runtime resource allocation overhead.

Embodiments of the invention uses a mechanism called statistical scheduling to determine the resource requirements of performers and to ensure, within an acceptable probability, that the scheduled performers are able to complete execution within a basic period. Clearly, an operating system could easily determine the total processor time needed to execute an arbitrary group of performers if it knows how long each one of them takes to execute. However, it is a theoretical impossibility for any automatic mechanism to determine each performer's execution time in advance. However, an operating system can measure the actual duration of a performer every time it is executed. Using some number of invocations, the operating system can compute summary statistics for the performer's execution duration.

Provided that future invocations of a performer exhibit similar execution behavior as previous invocations, these statistics let one or more operating system embodiments of the invention compute the probability of some set of performers running to completion in a known time interval.

Advantageously, embodiments of the invention do not need to verify that some group of performers can execute to completion successfully as part of the performer dispatch cycle. Instead, embodiments of the invention can perform this computation and other maintenance activities during any free time remaining between the end of invoking all the performers and the end of each basic period.

Since a statistically-verified group of performers retains a finite probability of executing beyond the end of the desired cycle time, embodiments of the invention provide a mechanism to detect and recover from schedule failure. Acknowledging and handling the possibility of scheduling failure improves the robustness of the invention vis-a-vis many other dynamically scheduled realtime operating systems.

Embodiments of the invention may comprise an operating system that performs admission control without requiring performers to accurately indicate their resource usage. The combination of efficient and admission controlled performers is ideal for providing flexible and dynamic realtime execution on highly interconnected low cost hardware devices.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 provides an illustration of scheduling and feedback mechanisms according to an embodiment of the invention.

Figure 2 provides an example of a schedule comprised of schedule tracks according to one or more embodiments of the invention.

Figure 3 provides an example of a performer state transition according to an embodiment of the invention.

Figures 4A-4C provide a graphical representation of a probability distribution according to an embodiment of the invention.

Figure 5 provides a verification process flow using performer information according to an embodiment of the invention.

Figure 6 provides a graph illustrating a latest start time according to an embodiment of the invention.

Figure 7 provides an overtime example according to an embodiment of the invention.

Figure 8 is a block diagram of one embodiment of a computer system capable of providing a suitable execution environment for an embodiment of the invention. DETAILED DESCRIPTION OF THE INVENTION

A method and apparatus for scheduling program code is described. In the following description, numerous specific details are set forth in order to provide a more thorough description of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without these specific details. In other instances, well-known features have not been described in detail so as not to obscure the invention.

Overview

Embodiments of the invention schedule program code for execution in a computer system. Program code, or other unit of execution, is referred to herein as a performer. A performer may, for example, execute in a computer system to generate realtime output (e.g., a sound or character in a video game, air traffic control information, etc.) or handle realtime input such as speech recognition or video processing.

In an embodiment of the invention, a performer is an object-oriented object that includes at least one method that provides its behavior. Each performer has associated information that includes historical execution information. According to one or more embodiments of the invention, the performer information is used to predict the future behavior of the performer. In one or more embodiments of the invention, a performer's information includes the amount of time (or other resource) that the performer has used, its state, and flags (e.g., progress flag) used in scheduling.

Embodiments of the invention are described with reference to the amount of time that a performer expends in executing. However, it should be apparent that other computer system resources may be used in place of time such as memory (or other storage), display, Input/Output (I/O) devices, etc.

In one or more embodiments of the invention, one or more performers are scheduled for execution during an execution interval that is referred to herein as a basic execution period or basic period. A basic period extends for a given amount of time some or all of which is used to execute performers. In one or more embodiments of the invention, the basic period is repeated such that the same or other scheduled performers may be executed.

In one or more embodiments of the invention, a scheduler manages a schedule of performers. The scheduler insures that the performers that are scheduled to execute during the basic period have at least a threshold probability (referred to as a safety factor, or Sf)) of executing to completion during the basic period. The safety factor is a configurable value between zero and one hundred percent. The value chosen for the safety factor may depend on the degree of certainty desired that the scheduled performers will complete during a basic period. For example, a value of 99% assigned to Sf may be used to insure that there is a 99% probability that all of the scheduled performers will complete execution within the basic period of time.

According to one or more embodiments of the invention, a schedule comprises none or more schedule tracks, each of which may be comprised of none or more performers. That is, a schedule may comprise a single schedule track of performers or multiple schedule tracks of performers. Where there are multiple schedule tracks, one schedule track is identified as the schedule whose performers are executed during a basic period. Unless otherwise indicated, schedule and schedule track may be used interchangeably. A performer may be included in more than one schedule track. In one or more embodiments of the invention, one schedule track is referred to as a lead schedule track. During a basic period, the performers that comprise the lead schedule track may be invoked for execution.

If a schedule, or schedule track, satisfies the safety factor, it is considered to be correct. In one or more embodiments of the invention, the scheduler uses a verifier to determine whether a schedule is "correct". In one or more embodiments of the invention, all of the schedule tracks are verified to determine whether the schedule is correct. That is, a schedule is considered to be correct, if each of the schedule tracks that comprise the schedule are correct. Alternatively, some number of the schedule tracks in the schedule may be verified to verify the schedule. For example, the current lead schedule may be the only schedule track of a schedule that is verified to verify the schedule. A schedule track is considered to be correct if the probability of all of the performers in the schedule track executing to completion in a single basic period exceeds the safety factor.

The correctness of a schedule may be verified more than once. For example, the correctness of a schedule may be verified prior to adopting it as the current schedule and invoking the performers within the schedule. Alternatively, the scheduler may re-verify a schedule that has previously been verified in response to an external request or on its own. The scheduler may opt to re-verify if, for example, a determination is made that not all of the performers are executing to completion within the basic period.

From time to time, the scheduler may be asked to add (or remove) one or more performers to (or from) a schedule. In the case of an addition, the scheduler amends the schedule, if it determines that the new schedule is correct. Otherwise, the scheduler can notify the requester (e.g., a multimedia application requesting to add an additional code fragment to the schedule). The requester may respond by making a different request (e.g., substituting other performers or a different number of performers). Where one or more performers are to be removed, the scheduler removes the performers and verifies that the resultant schedule is correct.

According to one or more embodiments of the invention, while the scheduler responds to requests to modify the schedule, the existing schedule's performers continue to execute until the verifier establishes the correctness of the modified schedule. The scheduler operates on a copy of the schedule that is being used by the conductor. The scheduler modifies and verifies the copy. A successfully verified copy of the schedule is posted (i.e., given) to the conductor. When a schedule is posted to the conductor, the conductor may switch to the new schedule.

During verification, a schedule may be found to be incorrect. In this case, one or more performers may be removed from the schedule. In one or more embodiments of the invention, the scheduler may attempt to determine which performers caused the schedule to be incorrect and remove them from the schedule. After the removal, the scheduler re-verifies the new schedule. The scheduler can repeat the process of removing performers and re-verifying the schedule until a correct schedule is achieved.

Once admitted to the schedule, an attempt is made to invoke each performer every basic period. A conductor iterates through a schedule to invoke each performer in the schedule during the basic period. The conductor may, however, determine that a performer cannot complete in the time remaining in the basic period. In this case, the conductor skips the ID

performer during that instance of the basic period. Whether or not the performer is executed, the conductor may update the performer's information to reflect the handling and execution of the performer during the basic period. The conductor may update a state associated with the performer. Where the conductor skips a performer, the conductor increments a "progress" value that reflects the number of basic periods of work that a performer needs to perform to remain synchronized with an external clock. Lastly, the conductor measures the resource use of the performer's execution and updates the performer's collected execution record with this new datum. For example, in one or more embodiments of the invention, the conductor may collect a performer's execution time, note the number of times the performer has been invoked and /or update the performer's execution behavior and state.

In one or more embodiments of the invention, an order is associated with the performers in a schedule. As performers are added to a schedule, they are added to the end of the schedule. The performers may be invoked in the order in which they occur in the schedule. A request can be made to modify the order of the performers in a schedule. The scheduler may require that the correctness of a reordered schedule be verified before it is used as the current schedule.

Figure 1 provides an illustration of scheduling and feedback mechanisms according to an embodiment of the invention. Schedule 108 is posted to conductor 104 by scheduler 102. Schedule 108 is comprised of one or more performers that are invoked by conductor 104. Conductor 104 iterates through schedule 108 and dispatches each performer, if it determines that there is enough time for the performer to execute to completion. As it 16

iterates through schedule 108, conductor 104 gathers information about each scheduled performer which is retained in performer information 110.

Initially, schedule 108 is verified by verifier 106. Conductor 104 may request that scheduler 102 use verifier 106 to re- verify schedule 108 at any time. Verifier 106 accesses performer information 110 to verify schedule 108. A copy of schedule 108 (i.e., schedule 112) may be used to verify schedule 108. Verifier 106 notifies scheduler 102 whether schedule 108 is successfully verified. If schedule 108 is not successfully verified, scheduler 102 may modify schedule 112 by removing one or more performers from schedule 112. Scheduler 102 may attempt to invoke verifier 106 to verify the modified schedule 112. If schedule 108 is successfully verified (either in its original form or in a modified form), scheduler 102 determines a latest start time for each performer. The latest start time is used by conductor 104 in determining whether a performer has sufficient time to complete its execution if it is invoked. If modifications are made to schedule 112, schedule 112 is given to conductor 104. Conductor 104 determines when to replace schedule 108 with schedule 112.

Scheduler 102 may receive a request (e.g., from an application) to add a performer to schedule 108. Scheduler 102 enforces an admission control policy such that a performer is added to schedule 108 only if schedule 108 can be successfully verified with the new performer as part of schedule 108. That is, a modified schedule 108 (e.g., schedule 112) including the new performer is verified by verifier 106. If the verification is unsuccessful, scheduler 102 does not add the new performer. Scheduler 102 may return a message to the requester indicating the unsuccessful status of the request. Embodiments of the invention provide a feedback mechanism of performer and /or schedule correctness. Each basic period, conductor 104 invokes performers listed in schedule 108 and collects information on each. Scheduler 102 hypothesizes that schedule 108 satisfies an hypothesis that there is at least an S_f (safety factor) probability that all of the performers that comprise schedule 108 execute to completion during a basic period. The validity of the hypothesis is determined as verifier 106 uses performer information 110 collected from previous basic periods to determine whether the probability of all the performers executing to completion at least equals the safety factor.

Schedule

According to one or more embodiments of the invention, a schedule is comprised of none or more schedule tracks. A schedule track can be comprised of none or more performers. In one or more embodiments of the invention, one of the schedule tracks is adopted as the current schedule track, or current schedule in each basic period. During a basic period, an attempt is made to execute each of the performers that comprise the current schedule track.

In one or more embodiments of the invention, a schedule is an array. Each entry in the schedule array identifies a schedule track each of which is comprised of none or more performers. According to this embodiment, one of the schedule tracks is used as the current schedule. An array index, referred to herein as the current lead, is used to identify an entry in the schedule array as the current schedule track. The performers that comprise the current lead's schedule track are iteratively dispatched, or invoked, as determined by the conductor. lo

Figure 2 provides an example of a schedule comprised of schedule tracks according to one or more embodiments of the invention. Schedule 202 is an array of schedule track entries 222A-222D each of which identify a schedule track. For example, entries 222A and 222D point to schedule tracks 204A and 204B, respectively.

Schedule tracks 204A and 204B are arrays that contain entries that identify (e.g., point to) performers in the schedule track. For example, schedule track 204A comprises performers pi, p2, p3, and p4 (i.e., performers 206A-206D). Similarly, schedule track 204B comprises performers p , p2, p5, and p4 (i.e., performers 206A-206B, 206E and 206D).

A schedule track may also specify the order in which performers are to be processed by the conductor during a basic period. For example, the order of the entries in schedule tracks 204A and 204B can be used to indicate the order in which the scheduled performers are to be invoked by the conductor. For example, in schedule track 204A, performer pi (i.e., 206A) is executed before performer p2 (i.e., 206B) which is executed before performer p3 (i.e., 206C). Performer p4 (i.e., 206D) is executed last. According to schedule track 204B, performer pi (i.e., 206A) is executed before performer p2 (i.e., 206B) which is executed before performer p5 (i.e., 206E). Performer p4 (i.e., 206D) is executed last.

The current lead identifies the schedule track that is being used by the conductor to execute performers in a basic period. If, for example, the current lead (e.g., a pointer) identifies entry 222D of schedule 202, schedule track 204B is the current schedule track and performers pi, p2, p5, and p4 (i.e., performers 206A-206B, 206E and 206D) are invoked by the conductor, if there are no overtimes detected by the conductor. Schedule Life Cycle

In one or more embodiments of the invention, a schedule has an associated life cycle that is based on its age. A schedule ages each time the conductor invokes the performer in the schedule. Where the schedule is comprised of multiple schedule tracks, each of the schedule tracks is aged independently. A schedule track ages each time the conductor invokes the performers listed in the schedule track. When each of the schedule tracks have sufficiently aged (i.e., reach a given age), the schedule as a whole is considered mature.

Schedule track age is a bounded approximation to the number of times that the conductor has attempted to invoke the performers listed in the schedule track. This corresponds to the number of samples contributing to the summary statistics used to predict the future behavior of the schedule track. The accuracy of statistical prediction increases with the number sample points available to determine summary statistics. Consequently, schedule track age can be used to determine the accuracy of the computations that the verifier uses to perform admission control.

While each additional sample of the schedule track's actual resource usage may provide an incremental improvement in the accuracy of the verifier's computations, the rate of improvement decreases rapidly.

Consequently, one or more embodiments of the invention may choose to bound the age of a schedule track or performer at an age where the verifier's accuracy is sufficient for the purpose of scheduling realtime code fragments. Certain actions associated with a schedule track (and hence the schedule containing the schedule track) can move the schedule track toward or away from maturity. For example, a schedule track that has been verified and is being used by the conductor to schedule the invocation of its performers ages each time that it is used by the conductor. A modification to the schedule track (e.g., addition, removal or restructuring of performers) is treated as a transition away from schedule maturity.

The age of the schedule track can be used to determine whether or not to request re- verifications of the schedule. For example, the conductor may request re-verifications of the schedule until the schedule track reaches a given age. This is because the conductor collects additional information each time it invokes the performers listed in a particular schedule track. The additional information improves the verifier's accuracy when determining the correctness of a particular schedule track. If each verification is successful and the schedule track is used enough times by the conductor, the schedule track achieves a certain age that the schedule is considered to be mature. The frequency of verification may be reduced or eliminated when a schedule reaches maturity. If one or more first- tier and /or second-tier overtimes occur with respect to a mature schedule, the age of the schedule may be reduced, resulting in additional verifications.

One or more embodiments of the invention treat the operation of adding new performers to a mature schedule as an experiment. The new performers may have unreliable or non-existent statistical summary information associated with them. However, an embodiment may add such performers to the schedule track regardless and then a few invocations thereafter attempt to verify the schedule track. If the schedule track remains correct, then the scheduler ages it to maturity as discussed above. Otherwise, the verifier corrects the schedule as discussed herein. In one or more embodiments of the invention, new performers may be added to the end of the schedule track so that no new performers can affect the operation of more mature performers placed ahead of them in the schedule track.

Performer Life Cycle

According to an embodiment of the invention, one or more states are associated with a performer that assist in determining whether the conductor and /or scheduler may access and /or alter the information contained in a performer. An embodiment of the invention uses these states to permit the conductor to dispatch performers while the scheduler responds to requests to asynchronously alter the schedule. That is, the conductor can dispatch performers from a schedule while the scheduler alters the schedule as a result of a schedule modification request. A performer's state may also be used by the conductor to mark a performer for special handling. . For example, certain of the ZOMBIE states may be used to determine whether the scheduler should remove a performer from a schedule. The following table presents examples of performer states according to one or more embodiments of the invention.

The above-described states may also be used to group performers as: performers not yet in any schedule (e.g., the NIL state), performers in a schedule and invoked if possible by the conductor (e.g., the SCHEDULED state and PREV OTIME state), and performers present in a schedule but not invoked (e.g., the SNOOZE, , ZOMBIE OT1, ZOMBIE OT2, ZOMBIE EXP and ZOMBIE RET states). An embodiment of the invention differentiates between the different zombie states so that it may indicate (e.g., to another performer or other program code) why the conductor is not executing the performer.

Figure 3 provides an example of a performer state transition according to an embodiment of the invention. Initially, a performer is in state 302 (i.e., NIL). When a performer is added to a schedule track, the performer's state is changed to state 306 (i.e., SCHEDULED).

If a first-tier overtime is detected with respect to a scheduled performer, the performer's state changes to state 304 (i.e., PREV_OTIME). The performer remains in state 304 until it is invoked in a subsequent basic period. If the number of successive first-tier overtimes exceed a threshold amount, the performer is moved from state 304 to state 310 (i.e., ZOMBIE).

State 310 (i.e., ZOMBIE) comprises four states: ZOMBIE_0Tl, ZOMBIE_0T2, ZOMBIE_EXP and ZOMBIE_RET. ZOMBIE_OTl identifies those performers whose successive first-tier overtimes exceed a maximum number. A performer in either state 304 (i.e., PREV_OTIME) or state 306 (i.e., SCHEDULED) can be retired (i.e., a voluntary removal from the schedule). A retired performer changes to state 310 (i.e., ZOMBIE_RET). A performer that generates a runtime exception changes from state 306 to state 310 (i.e., ZOMBIE_EXP). A performer in state 306 (i.e., SCHEDULED) that generates a second- tier overtime changes to state 310 (i.e., ZOMBIE_OT2).

A scheduled performer may remain part of a schedule but not get invoked by setting its destiny bit to SNOOZE. In this case, the performer changes from state 306 (i.e., SCHEDULED) to state 308 (i.e., SNOOZE). A snoozing performer remains in state 308 (i.e., SNOOZE) until a request is made to unsnooze it and the schedule containing the unsnoozed performer is verified. The unsnoozed performer returns to state 306 (i.e., SCHEDULED) if the schedule containing the performer is successfully verified.

According to an embodiment of the invention, a snoozed performer does not occupy time in the schedule. That is, a snoozed performer's execution history is not used to determine the correctness of the schedule track in which it is contained. However, unlike a retired performer, a snoozed performer's information (e.g., execution history and age) remains intact. When the snoozed performer is awakened, its age is as it was when it entered the snooze state. In contrast, a retired performer's age is reset to zero. The scheduler is therefore more likely to trust the execution history of a snoozed performer than a retired performer.

Performer Information

In one or more embodiments of the invention, information is associated with a performer that includes historical behavior information. A scheduled performer is not necessarily expected to execute in the same amount of time across invocations or basic period iterations. Variations may occur in a performer's execution time between basic period invocations. Embodiments of the invention identify whether execution variations in a performer's behavior can be tolerated. Execution variations are not tolerated where, for example, a performer's variations in inter-invocation execution times are considered to be causing an incomplete execution of the schedule (e.g., not all of the scheduled performers are able to execute to completion in a basic period). An unexpected execution time variance associated with one or more performers can result in a reduced ability to predict whether all of the scheduled performers can complete within a basic period. A performer that is experiencing wide fluctuations in execution times is therefore undesirable.

Correctness identifies whether a performer is executing within acceptable tolerances. A performer is considered to be correct if it is able to complete in a basic period and has an acceptable inter-invocation execution time variance. For example, an acceptable inter-invocation variance might be one where the variance around the mean is less than 1% of the performer's mean execution time. If the verifier determines that the schedule track containing some performer is incorrect (e.g., has a probability less than S_F of completing in a single basic period), it may attempt to correct the schedule track by removing incorrect performers.

Embodiments of the invention may require that all performers in a schedule track be correct as well as the schedule track itself being correct. However, other embodiments of the invention do not require that the performers that are contained in the schedule track be correct (i.e., only schedule track correctness as a whole is used as the criteria. In this case, if the schedule track as a whole is correct, it can contain incorrect performers.)

Embodiments of the invention use a statistical mechanism to determine the correctness of a schedule track. The verifier computes the correctness of a schedule track by combining historical information collected by the conductor for each performer. A performer's historical information is _r,_r

26

used to predict future behavior, for example. The probability of a performer executing to completion within a given amount of time is determined from a performer's history of execution in previous basic periods.

In general, across a given number of invocations, there is a true and unknowable probability distribution, p(t), associated with a performer p where p(t) is the probability of p taking t time to execute. In general, p(t) is a function of p's program code as well as a number of changing variables or conditions such as the hardware and software composition of a system. In one or more embodiments of the invention, a function, /p(t), is used to model p(t). That is, a function /p(t) may be used to predict the behavior of a performer. According to one or more embodiments of the invention, summary statistics computed from a performer's previous behavior are used as a parameter of /p(t).

A cumulative probability distribution, p(t), is the actual probability of a performer executing to completion in less than time t. Similarly, a cumulative probability distribution function, fp(t), provides a model of p(t) that, when appropriately parameterized with summary statistics computed from the recorded behavior of p, may be used to estimate the probability of a performer p executing to completion in less than time t. According to one or more embodiments of the invention, fp(t) is the integral of /p(t) (i.e., an area under the curve of /p(t)) from negative infinity to t and provides a cumulative probability. In an embodiment of the invention, the cumulative probability distribution function, fp(t) has the property that fp(t) < p(t). This means that, for example, if the performer has an 80% probability of executing in less than one millisecond, then fp( 1 millisecond ) will always compute a probability slightly less than 80%. In other words, fp(t) has the property of giving performers a little more time to execute than they actually need. This improves reliability.

An embodiment of the invention may choose an /p(t) that is parameterized with the mean and variance computed from the performer's observed execution times. In an embodiment of the invention, a mean execution time for p (i.e., m_x ^ j) in a basic period, i, and a variance for p (i.e., ^vx, p, i) ^are determined as follows:

where ip is the basic period in which p was first invoked, /?,; is the time taken by performer γ to execute in invocation j, and m^_χ „ j is the square of the mean.

In one or more embodiments of the invention, a schedule track containing a single performer p is correct when the cumulative probability distribution function, fp(t), for a duration equal to the basic period, Tβ, is greater than the safety factor, Sf, or threshold probability that all of the performers in the schedule will complete within the basic period. That is,

where

o

That is, fp(t) is the cumulative probability distribution of /p(t) integrated from negative infinity to TB. Since a performer does not take less than zero time to run,/p(t) is extremely small for t ranging from negative infinity to zero. Thus, a range from zero to T_ may be used if necessary to simplify the calculation of fp(t).

If an embodiment of the invention is to attempt to verify the correctness of a schedule track containing more than one performer, it must verify that the probability of executing all the performers to completion in T_ time exceeds Sf . Mathematically, this corresponds to showing:

πw ^{≥ 5}/

where

Pi

Σ<_P ^{≤ T}B

P=l

That is, that the product of the integrals for each of the scheduled performers satisfies Sf and that the sum of the execution times of the scheduled performers (i.e., tp) is less than the basic period time. This is difficult to determine, however, because the p, values of tp are unknown. Therefore, every combination of tp for the scheduled performers must be tested (requiring an infinite number of integrations) to ensure that the above conditions are true for each of the combinations. If all combinations satisfied the two conditions, it could be said that the schedule is correct. As is discussed in detail below, one or more embodiments of the invention adopt a normal distribution for / . The mathematical properties of the normal make it possible to verify a schedule track with only a single integration needed per track. Other probability distribution functions may also be used with embodiments of the invention.

Referring to Figure 4A, the x-axis and y-axis represent time and probability. Curve 402 represents a probability distribution for a single performer. Area 404 represents the probability that the performer will take between time 408 and time 410 to execute. The numerical value of area 404 (i.e., the probability) can be determined by integrating the probability distribution function represented by curve 402 between times 408 and 410.

Figure 4B illustrates a graph of a normal probability distribution (i.e., curve 422). Area 424 represents the probability that a performer will complete before the end of the basic period time (i.e., between time 428 and time 430, where time 428 is 0). If this probability is at least equal to Sf, the performer is considered to be correct.

In the case of Figure 4C, however, it is possible that the performer whose probability of completion is represented by area 434 does not have an adequate probability of completing its execution before the end of the basic period. Area 434 represents the probability that the performer will complete during the basic period (i.e., from time 438 to time 440). Area 436 presents the probability that the performer will require more than the basic period of time to complete execution. For an embodiment of the invention to consider a schedule track containing this performer to be correct, the integral of the probability distribution function represented by curve 432 between times 438 and 440 must be greater than Sf . Thus, if Sf includes area 434 and some portion of area 436 (i.e., area 434 is less than Sf), the schedule is not considered correct.

If an embodiment of the invention is to attempt to verify the correctness of a schedule track containing more than one performer, it must verify that the probability of executing every performer to completion exceeds Sf . As stated above, mathematically this is:

where

Pi

Σ^t _P ^{≤ T}B

P=l

In general, this is difficult to solve. Consequently, embodiments of the invention choose a function /p(t) to approximate a performer's true use of time that provides both a reasonable estimate of performer resource use and simultaneously makes it possible to verify the schedule. An embodiment of the invention where performers are units of realtime computation used to generate multimedia information, can use an appropriately parameterized normal distribution for /p(t). This is discussed further in the Verification section below. A normal distribution is

where μ and σ are the parameters of the distribution. That is, μ and σ are the mean and standard deviation of the normal distribution, respectively, where the standard deviation is the square root of the variance of the distribution. These two values are summary statistics. An embodiment of the invention using the normal distribution for /p(t) computes these values of μ and σ from performer p's resource usage behavior during previous invocations. An embodiment of the invention, could actually preserve a complete record of all of p's previous resource usage and use this to compute the actual values for these parameters. Alternatively, to reduce memory use, an embodiment of the invention could approximate the performer's mean and variance with some kind of moving averaging scheme.

A moving average scheme approximates the first and second moments around zero of a performer's resource usage without needing to store actual sample points. A performer's age provides a count of the number of times that the performer has been invoked in the current schedule. In an embodiment of the invention, a performer's age is initialized to zero upon its addition to the schedule and is incremented each time it is invoked until it reaches a value, H. That is, the age of a performer is bounded by H. According to an embodiment of the invention, the statistics that are gathered from H invocations are considered sufficient to conclude whether a performer is correct. In an embodiment of the invention, H is equal to 64.

The age of a performer, p, in basic period i (or ap_r i) is:

0 where p has not been invoked

^■ PA H if ^β , i-1 >H

\ ¹l γ, i-1 + 1 otherwise

In other words, unless an invoked performer's age has already reached H, the performer's age is incremented by one as a result of an invocation.

A performer's execution time, x, in basic period i (or Xp,i) is that portion of the basic period interval that is used to execute the performer. Interrupts that occur during a performer's execution may cause variations in a performer's execution time which may lead to a conclusion that the performer is incorrect. If interrupts are virtually uniformly distributed in time and of relatively uniform frequency, the time cost of interrupt handlers consumed in per-performer statistics may be ignored. Otherwise, according to an embodiment of the invention, the counter(s) used to collect performer execution time may be suspended when taking an interrupt.

An approximation of a performer's mean execution time for a given period, i, is the sum of a weighted execution time for a given period, i, and a weighted sample mean approximation determined for the prior period (i.e., i-

1). That is, the mean approximation (or fn_x n i) for basic period i is:

m ^χ,p,ι — (vD.l)⁺ + I ^mx

w.p,i-l

where ap,i is the age of the performer and Xp_rl is the execution time associated with the performer in basic period i.

A decaying approximation to the second moment around zero

(denoted as ^χ,r_> ,i) is determined for a performer for basic period i, according to an embodiment of the invention, as follows:

v x,_v,i = ^v X.VA-1

That is, the decaying approximation to the second moment around zero for a performer in basic period i is the sum of the weighted square of the execution time in basic period i and the performer's weighted decaying approximation to the second moment around zero in the previous basic period (i.e., i-1).

A performer p's approximation of variance (i.e., ^χ.p,i) for a given period, i, may be determined given the decaying approximation to the second moment around zero and sample mean approximation for the given period.

That is,

The above values are determined using historical execution information that is accumulated for a performer. However, a performer that has not been invoked does not have accumulated information as a result of its invocations. Therefore, embodiments of the invention permit the performer itself to provide an initial estimate of the mean and variance of its execution time. An embodiment of the invention may include these initial estimates in summary information computed from actual invocations of the performer. Alternatively, the initial estimates may discard them to reduce the influence incorrect initial estimates might have on scheduling calculations.

Overtime Determinations

Various conditions may result in a performer itself taking too long to execute or not having sufficient time remaining in a basic period so that it may have a reasonable likelihood of running to completion. These situations result in an overtime being associated with a performer. Overtimes may result in a performer being skipped during a basic period or being removed entirely from a schedule entirely. In one or more embodiments of the invention, an overtime may be a first- tier or second-tier overtime. According to one or more embodiments of the invention, a first-tier overtime occurs for some performer p when a pre-invocation determination is made that there is not enough time remaining in a basic period to execute p to completion. A second-tier overtime occurs when an executing performer does not complete by the end of the basic period in which it is invoked.

Ideally, each scheduled performer executes to completion within the basic period in which it is invoked. In one or more embodiments of the invention, upon invocation, a performer executes and upon completion of its execution the performer voluntarily yields control to the conductor. If a performer fails to voluntarily yield to the conductor before the end of a basic period, a second-tier overtime occurs. The conductor suspends the performer and designates the performer as causing a second-tier overtime. That is, the performer is given the status of a ZOMBIE_OT2. A performer that generates a second-tier overtime is considered to be incorrect and is removed from the current schedule (e.g., the current lead schedule track). In one or more embodiments of the invention, the scheduler may inform various program fragments that a performer has taken a second tier overtime.

To reduce the probability that a correct performer will generate a second-tier overtime, the conductor includes an overtime detection and avoidance mechanism. Before a performer is invoked, the conductor makes a determination whether the performer has enough time to complete during the basic period if it is invoked at the current time within the basic period. A latest start time may be associated with each scheduled performer that identifies, given a function /p(t) capable of predicting the execution time of a performer, the latest time in a basic period that the performer can be invoked and still have an adequate probability of executing to completion. According to one or more embodiments of the invention, before invoking a performer p in basic period i, the conductor verifies that:

fp(ti + T_B - t_c) > P_c

where Pc is a user-configurable parameter and represents a probability threshold of completion. Time ti is the time (e.g., a system clock or other timer) at the beginning of the basic period, i. Similarly, time tc is the current time. The time remaining in the basic period is the start time plus the amount of time allotted to a basic period, Tβ, minus the current time. That is, given the amount of time remaining in the basic period, is the probability of completing performer, p, at least equal to Pc- If the probability of completing the execution of p in basic period i is less than P , a first-tier overtime results. The conductor does not invoke p during i and increments a progress value associated with p as a result of the first-tier overtime. A performer consults its progress value to determine how much computation it needs to do in order to remain synchronized with the passage of basic periods.

For example, if the conductor skips a performer in two consecutive basic periods, the performer's progress value is set to three. If the conductor invokes the performer in the next basic period, the performer can choose to perform three basic periods of work, or skip some portion. For example, the performer might choose to skip generating samples for a sound that should have already been played. Otherwise, the conductor invokes performer p in basic period i and initializes p's progress value to one. A more detailed discussion of latest start time determinations is provided below.

Admission Control

In one or more embodiments of the invention, scheduled performers are invoked in each basic period and data is collected about a performer's invocation. Each performer's information is updated to reflect its activities during the basic period.

In one or more embodiments of the invention, a scheduler adds and /or removes performers to /from a schedule, and uses the information collected by the conductor to insure that the schedule as a whole is correct. In each basic period, information is collected for performers in the current schedule. The information can be used to verify the current schedule. To verify a schedule, the scheduler determines whether the scheduled performers have at least probability Sf of executing completely in a basic period. If the schedule fails the verification, one or more performers may be removed from the schedule until the schedule is successfully verified (i.e., until the scheduled performers have at least probability Sf of executing completely in a basic period based on the latest basic period results).

According to one or more embodiments of the invention, multiple first-tier or single second-tier overtimes (e.g., determined using the overtime detection and avoidance mechanisms of the conductor) may have already identified certain of the scheduled performers as zombies. Removal of these zombie performers may be sufficient to make the schedule correct.

Other performers that are determined to be incorrect may also be removed from the schedule. For example, a performer whose execution times are fluctuating widely from one basic period to the next might be removed. Such a performer is likely to cause a first-tier overtime and interfere with the operation of correct performers that occur later in the schedule.

The inter-invocation execution-time variance of a performer can be used to detect a performer whose execution times vary widely. During verification, larger variances will stretch the expected running time of the schedule beyond the length of the basic period. In one or more embodiments of the invention, the scheduler can remove a performer whose execution-time variance exceeds an empirically determined safe amount. For example, the scheduled performers are ordered in terms of the ratio of their variance to their mean (i.e., variance divided by mean). Some number of the performers with the largest such ratios could be culled from the schedule, both reducing the time needed to execute all the performers in the schedule and simultaneously increasing the predictability of the schedule.

In another embodiment of the invention, performers may be removed from an incorrect schedule based on the age of the performers. The younger the performer, the less reliable its associated statistical information. Further, it may be assumed that the younger (or newer) performers are more likely to be causing a once verified schedule to be unverifiable. In one or more embodiments of the invention, some number of the younger performers could be removed from the schedule to restore the schedule's correctness.

Additional criteria, as suitable for the purpose of detecting and removing performers which render a schedule unverifiable may be used. For example, an embodiment may remove performers based on a combination of zombie state, age variance, etc.

After the removal of some number of performers, the verifier attempts to verify the new schedule. The process of removing performers and verifying the schedule can be performed repeatedly until a successful verification occurs, or maximum number of attempts have been made resulting in the verifier determining that the schedule cannot be verified. If the schedule is modified, the scheduler returns the modified and verified schedule to the conductor. The conductor adopts the new schedule in a subsequent (e.g., next) basic period as soon as is convenient for it to do so. For example, in one or more embodiments of the invention, the conductor is permitted to only adopt a new schedule at the start of a basic period when all the performers in the previous basic period executed correctly to completion. For each basic period in which the schedule is used, the conductor gathers new data for the scheduled performers. The verifier will later use this information to re-verify the schedule. Where the age of a schedule track is being retained, a new schedule will have its age initialized to zero and incremented by the conductor each basic period that it is used.

Verification

In one or more embodiments of the invention, verification performed by a verifier determines whether a schedule track is correct. That is, whether a probability that each of the performers in a schedule track will execute to completion within the time of a basic period is at least equal to a safety factor. Verification can be performed on more than one of the schedule tracks that comprise a schedule. For example, verification may be performed on all of a schedule's schedule tracks. If all of a schedule's schedule tracks are successfully verified, the schedule is considered to be verified or correct.

Alternatively, verification is performed on the current lead schedule track only. As mentioned above, a schedule track is correct if and only if it satisfies these two equations.

p=\ Pi

p=\

That is, that the product of the integrals of fp(t) for the scheduled performers satisfies Sf and that the sum of the tpS for the scheduled performers is less than Tβ. These conditions do not require that the all of the performers in a schedule be correct in order for the schedule to be correct.

One or more embodiments of the invention use a narrower criteria of schedule track correctness where every performer must also be correct, or:

where f^"lp(Sf) is the inverse integral of fp(Sf). That is, the sum of the time needed for each performer to have Sf probability of completion must be less than Tβ to satisfy the above criteria. Or alternatively stated, each performer must be correct.

As previously stated, embodiments of the invention use a function for / (t) (e.g., a normal) to greatly simplify schedule verification . As mentioned above, one or more embodiments of the invention set fit) to be equal to a parameterized normal distribution for this purpose. Then, such embodiments of the invention can use a single combined function, /l...p_j(t) to verify the correctness of a schedule track where each performer's probability distribution is considered to be a normal. Owing to the properties of the normal distribution, /l...p_j(t) is also normal with a mean and variance determined as follows:

and

where ^mx,_P,, and ^vx,_P,, are the per-performer mean and variance respectively.

In an embodiment of the invention, the mean and variance may be determined as follows:

Alternatively, an embodiment of the invention could approximate these values (i.e., fϊiχ.p,i and ^v^x,p,i) with the decaying averaging scheme discussed above.

According to one or more embodiments of the invention, from ^v/,i-/. , a standard deviation ^σ j ^~ J'/ Λ-P, is determined and is used along with the mean to parameterize the normal distribution in the following fashion:

An embodiment of the invention uses the normal function to verify the correctness of a schedule track as a whole by insuring that the following relationship holds: ?Λ Pi (t)dt ≥ S f

Using a normal distribution for p(t) provides a lower bound which grows tighter as performer variability and resource needs increase. That is, a normal distribution more accurately estimates performer behavior at higher variances and resource (e.g., processor) use, i.e., those levels where accurate estimates are most useful. Accurate behavior prediction is not as important for those performers that use a lesser amount of resources as long as the chosen p(t) provides a lower bound for p(t).

The information associated with each performer in a schedule track is used to verify the schedule track. Figure 5 provides a verification process flow using performer information according to an embodiment of the invention. At step 502, a mean and variance around zero are determined for each performer in a schedule track. According to an embodiment of the invention, a performer's (actual or approximate) mean and variance around zero are computed using the performer's historical information.

At step 504, a variance around the mean is determined for each of the performers in the schedule track. In step 506, these per-performer values are summed, substituted into the following equation and the result of the integral is determined:

At step 508, a determination is made whether the schedule track's probability of completion as determined in step 506 with the above integral is at least as great as the safety factor. If not, the schedule track is determined to be incorrect at step 512. As previously discussed, performers may be culled from an incorrect schedule and the schedule re-verified, if the schedule track is determined to be incorrect at step 512. If the schedule track's probability of completion is at least as great as the safety factor, the schedule track is found to be correct.

Figure 5 can be repeated for all (or some other number) of the schedule tracks in a schedule.

Latest Start Time

In one or more embodiments of the invention, if a schedule is successfully verified, the scheduler computes the latest start time for each performer before giving the verified schedule to the conductor. The latest start time is used by the conductor to detect first-tier overtimes, thereby avoiding second-tier overtimes.

In an embodiment of the invention, a performer's latest start time, lp(Pc)/ is determined by setting the performer's cumulative probability distribution function (which is parameterized with the performer's mean and variance) equal to P_c and solving for t. That is,

Pc = fp(t)

By solving this equation for t, the scheduler determines the amount of time that p needs to have at least probability P_c of executing to completion.

Figure 6 provides a graph illustrating a probability distribution curve for determining a latest start time according to an embodiment of the invention which uses a normal distribution for/p(t). The x-axis and y-axis represent probability and time, respectively. Curve 602 is a normal probability function. The area 604 under curve 602 from negative infinity to t equals Pc- Performer p's latest start time, lp(Pc), is:

lp(Pc) = TB - 1

or, the amount of time that can be expended from the beginning of a single basic period prior to invoking p if p is going to have at least probability Pc of executing to completion.

Before executing performer p, the conductor examines p's latest start time, lp(P ), to determine whether the time remaining in the basic period is at least as much as is needed to execute p to completion. According to one embodiment of the invention, the scheduler determines whether:

t_c - ti < Tβ - t

where tc and ti are time values that reflect the current time and the time at the start of the basic period, respectively. The amount of the basic period's time that is not needed to perform p is determined by subtracting t from Tβ. Thus, the scheduler invokes p if the time expended by performers already invoked in the basic period is less than the amount of a basic period's time that is needed to execute p.

Figure 7 provides an overtime example according to an embodiment of the invention. Time line 702 comprises a basic period that begins at a start time, ti, and an end time equal to t_t + 60. Consequently, the duration of the basic period, Tβ, is 60. In this example, the current time, t_c, is 30. That is, the performers that have been invoked have taken an elapsed time of 30, or tc - 1[.

The conductor determines whether a first-tier overtime exists for performer p. In other words, the conductor determines whether or not performer p has enough time to execute to completion if it is invoked at time tc- Two examples of lp(Pc) are given along time line 702 for performer, p.

Example 704 of lp(P_c) is equal to 20 and example 706 of lp(P ) is 45. As indicated above, lp(Pc) identifies the maximum amount of the basic period that is available for the execution of those performers that are invoked prior to performer p. In the case of example 704 of lp(Pc), the value of tc indicates that the previously invoked performers consumed an amount of time that exceeds the available amount of time. Therefore, there is not enough time remaining in the basic period for performer p to execute. That is, tc-ti is not less than lp(Pc). In the current basic period, a first-tier overtime occurs with respect to performer p with respect to example 704 of lp(Pc) (i.e., 20). The conductor updates p's state and skips p in the current basic period.

In the case of example 706, lp(Pc) is equal to 45. The performers invoked prior to performer p were able to execute by time tc (i.e., 30). Thus, the current time is less than p's latest start time. Therefore, the conductor invokes performer p in the basic time period.

Verification Example

According to one or more embodiments of the invention, a schedule is shown to be correct by verifying the schedule tracks that comprise the schedule. To verify a schedule track, a mean and variance is determined which is the combination of the means and variances of the performers that constitute a schedule track. The combined mean and variance are substituted into a probability distribution function that models the behavior of the performers and the function is integrated over a period of time (e.g., from negative infinity to Tβ). Where the integral value is at least equal to the 40

safety factor, the schedule track is considered to be correct and verified. That is, a schedule track is correct where:

The following provides an example of an/p(t) (or n(t;_,_)) probability distribution function used in one or more embodiments of the invention:

\ ( t-_ (t;μ,σ) = ^e

where μ is the distribution's mean and σ is its standard deviation (i.e., the square root of the variance). As described above, a combined mean, m l...pp and variance, v l...p in a normal distribution are used to avoid integrating over a linear range of performers. Therefore, the test for correctness becomes:

\ " n(t; μ,σ) ≥ S

where:

σ - x,γ,ι p=l

(i.e., the square root of the sum of the execution variances of the performers in the schedule track in basic period i) and

(i.e., the sum of the execution means of the schedule track's performers in basic period i). 46

The result from the left side of the integral is compared to a configurable value for the safety factor to determine whether it is at least as much as the safety factor. If so, the schedule track is successfully verified. If not, the schedule track's verification fails.

According to one or more embodiments of the invention, if verification is successful, a latest start time is determined for each of the performers. As described above, a latest start time is determined for a performer p by setting the distribution function equal to a configurable probability value, P_c and solving for t. That is,

where ⁿ(t^'>H>^σ) is a normal distribution as defined above, ^mχ,_P,ι is a mean computed from p's recorded historical behavior and ^vχ,_P,< is a variance computed from the same data. Then, as discussed above, lp(Pc) is set to the difference between the size of a basic period and t..

Restructuring

In one or more embodiments of the invention, the structure of a schedule may be adjusted. The restructuring may be, for example, resetting some portion of the information associated with a performer (e.g., the performer's age). Alternatively, the restructuring may change the order of performers in a schedule.

For example, an application may wish to reset a performer's information, if the performer has experienced a reduction in its use of processing resources. For example, if a user of the application reduces the window size for a video decompression performer, the application may make a "reset" request. In response, the age of the performer is set to zero. The previously accumulated information collected for the performer is discarded and the data accumulated thereafter more accurately reflects the change in the performer's behavior (e.g., a reduction in processing needs). Thus, the scheduler is more promptly notified of the change in the performer's behavior. Where the performer is using less processor time (or another resource), for example, this information is promptly communicated using the "reset" mechanism.

A "reordering" mechanism may be used to restructure a group of performers in a schedule. The "reordering" mechanism of one or more embodiments of the invention may be used to change an application's installed performers in response to an application failing to install its performers into a schedule or receiving notification that the conductor or scheduler culled some of its performers.

A user request to alter the application's quality of service (QoS) may invoke the "reordering" mechanism as well. An application may provide an interface to a virtual world that allows the user to specify the level of rendering of its graphics output. That is, depending on the capabilities of the underlying hardware and the proportion of the processor available to the application, the application would include a range of renderer performers, each capable of delivering a different quality of service level. For example, there might be a wire frame renderer, flat-shaded renderer, Phong-shaded renderer, and ray-traced renderer performer.

The application permits the user to select the renderer as desired. The user may request a change from the unattractive but less processor intensive flat-shaded renderer to a more visually compelling ray-traced renderer. The application would set the destiny bits of the performers making up the flat- shaded renderer with snooze and set the destiny bits of the ray-traced rendered to either add or unsnooze as appropriate. The application would call the "reordering" mechanism with its performer group to exchange the flat-shaded renderer for the ray-traced renderer.

In one or more embodiments of the invention, a reordering is based on a destiny value associated with the performers to be reordered. This mechanism creates a new schedule by first removing the already scheduled performers in the "reorder" group from the schedule, modifying the "reorder" group based on each performer's destiny bit value and appending the resulting "reorder" group of performers to the end of the schedule. If the new schedule is successfully verified, the new schedule is posted as the current schedule and the destiny value is cleared for each of the performers.

Thus, destiny values may be used to modify an application's complement of performers. The following table provides examples of destiny bit values according to an embodiment of the invention:

In an embodiment of the invention, schedule modifications occur if the restructured schedule becomes the current schedule. The destiny bit may also be used to temporarily remove a performer by setting the destiny bit to "snooze." That is, by setting a performer's destiny bit to "snooze," the performer is not invoked during the basic period. However, it may be invoked during the basic period by setting its destiny bit to "unsnooze" and the schedule track that contains the unszoozed performer is verified. 50

Embodiment of Computer Execution Environment (Hardware)

An embodiment of the invention can be implemented as computer software in the form of computer readable code executed on a general purpose computer such as computer 800 illustrated in Figure 8. A keyboard 810 and mouse 811 are coupled to a bi-directional system bus 818. The keyboard and mouse are for introducing user input to the computer system and communicating that user input to processor 813. Other suitable input devices may be used in addition to, or in place of, the mouse 811 and keyboard 810. I/O (input/output) unit 819 coupled to bi-directional system bus 818 represents such I/O elements as a printer, A/V (audio/video) I/O, etc.

Computer 800 may include a video memory 814, has a main memory 815 and may include mass storage 812, all coupled to bi-directional system bus 818 along with peripherals such as a keyboard 810, mouse 811 and processor 813. The mass storage 812 may include both fixed and removable media, such as magnetic, optical or magnetic optical storage systems or any other available mass storage technology. Bus 818 may contain, for example, thirty-two address lines for addressing video memory 814 or main memory 815. The system bus 818 also includes, for example, a 32-bit data bus for transferring data between and among the components, such as processor 813, main memory 815, video memory 814 and mass storage 812. Alternatively, multiplex data /address lines may be used instead of separate data and address lines.

In one embodiment of the invention, the processor 813 is a microprocessor manufactured by Motorola, such as the 680X0 processor or a microprocessor manufactured by Intel, such as the 80X86, or Pentium processor, or a SPARC microprocessor from Sun Microsystems, Inc. However, any other suitable microprocessor or microcomputer may be utilized. Processor 813, or other mechanism, is used to time the execution of a performer. Main memory 815 is comprised of dynamic random access memory (DRAM). Video memory 814 is a dual-ported video random access memory. One port of the video memory 814 is coupled to video amplifier 816. The video amplifier 816 is used to drive the cathode ray tube (CRT) raster monitor 817. Video amplifier 816 is well known in the art and may be implemented by any suitable apparatus. This circuitry converts pixel data stored in video memory 814 to a raster signal suitable for use by monitor 817. Monitor 817 is a type of monitor suitable for displaying graphic images.

Alternatively, the video memory could be used to drive a flat panel or liquid crystal display (LCD), or any other suitable data presentation device.

Computer 800 may also include a communication interface 820 coupled to bus 818. Communication interface 820 provides a two-way data communication coupling via a network link 821 to a local network 822. For example, if communication interface 820 is an integrated services digital network (ISDN) card or a modem, communication interface 820 provides a data communication connection to the corresponding type of telephone line, which comprises part of network link 821. If communication interface 820 is a local area network (LAN) card, communication interface 820 provides a data communication connection via network link 821 to a compatible LAN. Communication interface 820 could also be a cable modem or wireless interface. In any such implementation, communication interface 820 sends and receives electrical, electromagnetic or optical signals which carry digital data streams representing various types of information.

Network link 821 typically provides data communication through one or more networks to other data devices. For example, network link 821 may provide a connection through local network 822 to local server computer 823 or to data equipment operated by an Internet Service Provider (ISP) 824. ISP 824 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the "Internet" 825. Local network 822 and Internet 825 both use electrical, electromagnetic or optical signals which carry digital data streams. The signals through the various networks and the signals on network link 821 and through communication interface 820, which carry the digital data to and from computer 800, are exemplary forms of carrier waves transporting the information.

Computer 800 can send messages and receive data, including program code, through the network(s), network link 821, and communication interface 820. In the Internet example, remote server computer 826 might transmit a requested code for an application program through Internet 825, ISP 824, local network 822 and communication interface 820.

The received code may be executed by processor 813 as it is received, and/or stored in mass storage 812, or other non-volatile storage for later execution. In this manner, computer 800 may obtain application code in the form of a carrier wave. In accordance with an embodiment of the invention, examples of such downloaded applications include one or more elements of a runtime environment, such as the virtual machine, class loader, class bytecode files, class libraries and the apparatus that implements the single compiler architecture described herein.

Application code may be embodied in any form of computer program product. A computer program product comprises a medium configured to store or transport computer readable code or data, or in which computer readable code or data may be embedded. Some examples of computer program products are CD-ROM disks, ROM cards, floppy disks, magnetic tapes, computer hard drives, servers on a network, and carrier waves.

The computer systems described above are for purposes of example only. An embodiment of the invention may be implemented in any type of computer system or programming or processing environment, including embedded devices (e.g., web phones, etc.) and "thin" client processing environments (e.g., network computers (NC's), etc.) that support a virtual machine. One or more embodiments of the invention may be implemented in multiprocessor systems.

Thus, a method and apparatus for scheduling code fragments has been described in conjunction with one or more specific embodiments. The invention is defined by the claims and their full scope of equivalents.

Claims

CLAIMSWhat is claimed is:

1. A statistical scheduling method in at least one computer system comprising:

identifying a plurality of performers that comprise a schedule, said plurality of performers comprising program code; determining a probability of completion of said schedule; determining whether said probability of completion of said schedule satisfies a threshold probability; identifying said schedule as correct if said schedule satisfies said threshold probability.

2. The method of claim 1 further comprising:

obtaining information associated with said plurality of performers.

3. The method of claim 2 wherein said information associated with said plurality of performers comprises at least one execution time associated with each of said plurality of performers.

4. The method of claim 1 wherein said determining a probability of completion of said schedule further comprises:

determining an aggregate mean of execution time and variance to said aggregate mean for said plurality of performers; determining a probability of completion of said plurality of performers using said aggregate mean and said variance.

5. The method of claim 4 wherein said determining a probability of completion of said plurality of performers using said aggregate mean and said variance comprises:

obtaining a probability distribution function comprising a mean component and a variance component, said probability distribution function modeling an actual probability distribution that said each of said plurality of performers execute to completion in a given period of time; substituting said aggregate mean in place of said mean component and said variance in place of said variance component; integrating said probability distribution function for said given period of time.

6. The method of claim 5 wherein said actual probability distribution is a normal distribution, said determining an aggregate mean of execution time and variance to said aggregate mean for said plurality of performers further comprises:

determining said aggregate mean comprising a mean of execution time associated with each of said plurality of performers; determining said variance comprising a variance associated with each of said plurality of performers.

7. The method of claim 6 wherein said mean of execution time associated with each of said plurality of performers is an actual mean of execution time and said variance associated with each of said plurality of performers is an actual variance.

8. The method of claim 6 wherein said mean of execution time associated with each of said plurality of performers is an approximation of an actual mean of execution time and said variance associated with each of said plurality of performers is an approximation of an actual variance.

9. The method of claim 1 further comprising:

scheduling execution of said plurality of performers using said correct schedule.

10. The method of claim 9 wherein said execution of said plurality of performers occurs within a time period, said scheduling execution of said plurality of performers using said schedule further comprises:

determining whether said one of said plurality of performers has time to execute within said time period; invoking one of said plurality of performers if said one of said plurality of performers has time to execute to completion within said time period; identifying said one of said plurality of performers as causing a first tier overtime if said one of said plurality of performers has insufficient time within said time period to execute to completion; identifying said one of said plurality of performers as causing a second tier overtime if said one of said plurality of performers is invoked as is incapable of completing before the expiration of said time period.

11. The method of claim 10 wherein said determining whether said one of said plurality of performers has time to execute within said time period further comprising:

determining a latest start time for said one of said plurality of performers, said latest start time identifying the latest point within said time period such that there is an acceptable probability of completion of said one of said plurality of performers within said given period of time.

12. The method of claim 1 further comprising:

performing the following, if said schedule does not satisfy said threshold probability: removing at least one of said plurality of performers from said schedule to generate a modified schedule; determining whether a probability of completion of said modified schedule satisfies said threshold probability; identifying said modified schedule as correct if said modified schedule satisfies said threshold probability.

13. The method of claim 12 wherein said removing at least one of said plurality of performers from said schedule to generate a modified schedule further comprises:

comparing an age associated with each of said plurality of performers; removing said at least one of said plurality of performers where said at least one of said plurality of performers are the younger performers. Do

14. The method of claim 12 wherein said at least one of said plurality of performers was unable to execute to completion within at least one previous time period, said method further comprising:

rendering said one of said plurality of performers nonexecutable in said schedule.

15. The method of claim 1 wherein said determining whether said probability of completion of said schedule satisfies a threshold probability further comprises:

determining that said schedule satisfies said threshold probability if said probability of completion exceeds said threshold probability.

16. A scheduling admission control method in at least one computer system comprising:

obtaining information associated with a first plurality of performers that comprise a schedule and a second plurality of performers, each of said first plurality of performers and said second plurality of performers comprising program code; determining a probability of completion of said first plurality of performers and said second plurality of performers using said information; adding said second plurality of performers to said schedule if said probability of completion satisfies a safety threshold probability.

17. The method of claim 16 wherein said second plurality of performers are added to the end of said schedule.

18. The method of claim 16 wherein said probability of completion is a probability of completion within a given period of time.

19. The method of claim 18 wherein said determining a probability of completion of said first plurality of performers and said second plurality of performers further comprises:

integrating a combined probability distribution function for said given period of time.

20. The method of claim 19 wherein a combined mean and variance for said first plurality of performers and said second plurality of performers is incorporated in said combined probability distribution function.

21. The method of claim 16 wherein said combined probability distribution function is a normal.

22. A statistical scheduling system comprising:

a verifier configured to verify whether a schedule has at least a threshold probability of executing completely within a time period; a scheduler coupled to said verifier, said scheduler configured to invoke said verifier and to modify said schedule; a conductor configured to iterate through a plurality of program code comprising said schedule and determine whether one of said plurality of program code is to be invoked during said time period.

23. The system of claim 22 wherein said scheduler is further configured to determine a latest start time in said time period for each of said plurality of program code.

24. The system of claim 23 wherein said conductor is further configured to invoke said one of said plurality of program code, if said latest start time of said one of said plurality of program code has not been exceeded. 60

25. The system of claim 22 wherein said conductor is further configured to identify whether said one of said plurality of program code extends beyond said time period.

26 The system of clam 22 wherein said conductor is configured to iterate through said plurality of program code asynchronously with said verifier and said scheduler.

27. The system of claim 22 wherein said conductor is further configured to gather information for said plurality of program code.

28. The method of claim 27 wherein said information comprises execution time.

29. The method of claim 27 wherein said information comprises a state.

30. A computer program product comprising:

a computer usable medium having computer readable program code embodied therein for statistical scheduling comprising:

computer readable program code configured to cause a computer to identify a plurality of performers that comprise a schedule, said plurality of performers comprising program code; computer readable program code configured to cause a computer to determine a probability of completion of said schedule; computer readable program code configured to cause a computer to determine whether said probability of completion of said schedule satisfies a threshold probability; computer readable program code configured to cause a computer to identify said schedule as correct if said schedule satisfies said threshold probability.

31. The computer program product of claim 30 further comprising:

computer readable program code configured to cause a computer to obtain information associated with said plurality of performers.

32. The computer program product of claim 31 wherein said information associated with said plurality of performers comprises at least one execution time associated with each of said plurality of performers.

33. The computer program product of claim 30 wherein said computer readable program code configured to cause a computer to determine a probability of completion of said schedule further comprises:

computer readable program code configured to cause a computer to determine an aggregate mean of execution time and variance to said aggregate mean for said plurality of performers; computer readable program code configured to cause a computer to determine a probability of completion of said plurality of performers using said aggregate mean and said variance.

34. The computer program product of claim 33 wherein said computer readable program code configured to cause a computer to determine a probability of completion of said plurality of performers using said aggregate mean and said variance comprises:

computer readable program code configured to cause a computer to obtain a probability distribution function comprising a mean component and a variance component, said probability distribution function modeling an actual probability distribution that said each of said plurality of performers execute to completion in a given period of time; computer readable program code configured to cause a computer to substitute said aggregate mean in place of said mean component and said variance in place of said variance component; computer readable program code configured to cause a computer to integrate said probability distribution function for said given period of time.

35. The computer program product of claim 34 wherein said actual probability distribution is a normal distribution, said computer readable program code configured to cause a computer to determine an aggregate mean of execution time and variance to said aggregate mean for said plurality of performers further comprises:

computer readable program code configured to cause a computer to determine said aggregate mean comprising a mean of execution time associated with each of said plurality of performers; computer readable program code configured to cause a computer to determine said variance comprising a variance associated with each of said plurality of performers.

36. The computer program product of claim 35 wherein said mean of execution time associated with each of said plurality of performers is an actual mean of execution time and said variance associated with each of said plurality of performers is an actual variance.

37. The computer program product of claim 35 wherein said mean of execution time associated with each of said plurality of performers is an approximation of an actual mean of execution time and said variance associated with each of said plurality of performers is an approximation of an actual variance.

38. The computer program product of claim 30 further comprising:

computer readable program code configured to cause a computer to schedule execution of said plurality of performers using said correct schedule.

39. The computer program product of claim 38 wherein said execution of said plurality of performers occurs within a time period, said computer readable program code configured to cause a computer to schedule execution of said plurality of performers using said schedule further comprises:

computer readable program code configured to cause a computer to determine whether said one of said plurality of performers has time to execute within said time period; computer readable program code configured to cause a computer to invoke one of said plurality of performers if said one of said plurality of performers has time to execute to completion within said time period; computer readable program code configured to cause a computer to identify said one of said plurality of performers as causing a first tier overtime if said one of said plurality of performers has insufficient time within said time period to execute to completion; computer readable program code configured to cause a computer to identify said one of said plurality of performers as causing a second tier overtime if said one of said plurality of performers is invoked as is incapable of completing before the expiration of said time period.

. _

65

40. The computer program product of claim 39 wherein said computer readable program code configured to cause a computer to determine whether said one of said plurality of performers has time to execute within said time period further comprising:

computer readable program code configured to cause a computer to determine a latest start time for said one of said plurality of performers, said latest start time identifying the latest point within said time period such that there is an acceptable probability of completion of said one of said plurality of performers within said given period of time.

41. The computer program product of claim 30 further comprising:

computer readable program code configured to cause a computer to perform the following, if said schedule does not satisfy said threshold probability: removing at least one of said plurality of performers from said schedule to generate a modified schedule; determining whether a probability of completion of said modified schedule satisfies said threshold probability; identifying said modified schedule as correct if said modified schedule satisfies said threshold probability.

42. The computer program product of claim 41 wherein said removing at least one of said plurality of performers from said schedule to generate a modified schedule further comprises:

comparing an age associated with each of said plurality of performers; removing said at least one of said plurality of performers where said at least one of said plurality of performers are the younger performers. , .

66

43. The computer program product of claim 41 wherein said at least one of said plurality of performers was unable to execute to completion within at least one previous time period, said computer program product further comprising.

computer readable program code configured to cause a computer to render said one of said one of said plurality of performers nonexecutable in said schedule.

44. The computer program product of claim 30 wherein said computer readable program code configured to cause a computer to determine whether said probability of completion of said schedule satisfies a threshold probability further comprises:

computer readable program code configured to cause a computer to determine that said schedule satisfies said threshold probability if said probability of completion exceeds said threshold probability.

45. A computer program product comprising

a computer usable medium having computer readable program code embodied therein for scheduling admission control comprising:

computer readable program code configured to cause a computer to obtain information associated with a first plurality of performers that comprise a schedule and a second plurality of performers, each of said first plurality of performers and said second plurality of performers comprising program code; computer readable program code configured to cause a computer to determine a probability of completion of said first plurality of performers and said second plurality of performers using said information; computer readable program code configured to cause a computer to add said second plurality of performers to said schedule if said probability of completion satisfies a safety threshold probability.

46. The computer program product of claim 45 wherein said second plurality of performers are added to the end of said schedule.

47. The computer program product of claim 45 wherein said probability of completion is a probability of completion within a given period of time. 0

48. The computer program product of claim 47 wherein said computer readable program code configured to cause a computer to determine a probability of completion of said first plurality of performers and said second plurality of performers further comprises:

computer readable program code configured to cause a computer to integrate a combined probability distribution function for said given period of time.

49. The computer program product of claim 48 wherein a combined mean and variance for said first plurality of performers and said second plurality of performers is incorporated in said combined probability distribution function.

50. The computer program product of claim 49 wherein said combined probability distribution function is a normal.