WO2005083566A2

WO2005083566A2 - Method and system for restrained budget use with controlled budget transfer

Info

Publication number: WO2005083566A2
Application number: PCT/IB2005/050585
Authority: WO
Inventors: Reinder Jaap Bril
Original assignee: Koninklijke Philips Electronics, N.V.; U.S. Philips Corporation
Priority date: 2004-02-18
Filing date: 2005-02-16
Publication date: 2005-09-09
Also published as: EP1721251A2; JP2007523423A; CN1922577A; WO2005083566A3; KR20070005596A

Abstract

A method (10, 30) for controlling multiple tasks in a real-time operating system (20) assigns priorities to two or more tasks (24, 25). A first task (24) is assigned to be a More Important Task. A second task (25) is assigned to be a Less Important Task. A Guaranteed Budget Margin is then allocated to the More Important Task along with a More Important Guaranteed Budget. A Less Important Guaranteed Budget is also allocated to the Less Important Task. At some point during execution, the higher priority or More Important Task (24) may then determine that the More Important Task no longer requires the Guaranteed Budget Margin, in which case, a Conditionally Guaranteed Budget Margin is then allocated to the Less Important Task (24). Upon reclaiming of the Guaranteed Budget Margin from the LIT, the MIT waits either a predetermined static time period or a dynamic time period determined upon release or reclaiming of the GBM, whichever is longer, before receiving the GBM or before the CGBM is removed from the LIT.

Description

METHOD AND SYSTEM FOR RESTRAINED BUDGET USE WITH CONTROLLED BUDGET TRANSFER

The present invention relates generally to methods and apparatuses for managing resources in operating systems, and more particularly to a method and apparatus for managing resources in an operating system that functions in real-time. Conditional Guaranteed Budgets (CGBs) were originally introduced as a mechanism at the level of the budget scheduler, aiming at improvements of the cost- effectiveness of systems. The basic idea behind the CGB is as follows. A more important task (MIT) receives a more important guaranteed budget (MIGB), and in addition a guaranteed budget margin (GBM) to anticipate a structural load increase. A less important task (LIT) receives a less important guaranteed budget (LIGB). Moreover, the LIT receives a conditionally guaranteed budget margin (CGBM) when the MIT consistently does not use its GBM. The problem with this original type of CGB is that the allocation of the CGBM is implicit. We will refer to this original type of CGB as weak CGB. The term weak refers to the fact that the guarantee is weak, e.g., the MIT may use (part of) its GBM, and therefore the LIT may receive less than its CGBM. U.S. Provisional Patent Application No. 60/519,811 [attorney docket no. 613652] improves upon this notion by making the allocation explicit. We will refer to the latter kind of CGB as strong CGB. The term strong refers to the fact that the guarantee is strong, e.g. the MIT can use its GBM if and only if it claimed the GBM, and the LIT can actually count on the CGBM when the MIT has released (and not yet re-claimed) its GBM. When the MIT claims its GBM, it receives it instantaneously, i.e. during its current budget period. As a consequence, the CGBM is also withdrawn instantaneously from the LIT. Both kinds of CGBs have their merits and uses in systems. As an example, when an application such as an input reader cannot be scaled and therefore needs a worst-case budget allocation to accommodate its load fluctuations, strong CGBs cannot be applied, and we therefore need weak CGBs if we want to improve the cost- effectiveness of the system. As additional background, there are essentially two types of budget consumption by tasks: ^• Synchronous behavior: the task works in synchrony with the budget consumption (i.e., it starts when the budget is replenished, and completes its work within the budget period). Asynchronous behavior: the task does not work in synchrony with its budget. It may work-ahead, or lag behind, compared to its budget consumption. Asynchronous behavior is often used to smoothen out the load. In certain instances, instantaneous loss of the CGBM from the LIT can cause problems. The present invention is therefore directed to the problem of developing a method and apparatus for improving resource use in an importance-based, real-time operating system without causing an instantaneous withdrawal of the CGBM. The present invention solves these and other problems by providing a look- ahead mechanism for indicating to the scheduler that when the MIT reclaims its Guaranteed Budget Margin a predetermined period of time will occur before the MIT actually requires the Guaranteed Budget Margin to thereby enable the LIT to smoothly transition out of the use of the Conditionally Guaranteed Budget Margin. Moreover, according to another aspect of the present invention, the look- ahead mechanism employs a static time period that enables the scheduler to know that the MIT will not need the GBM for at least the static time period after notifying the scheduler that the MIT will soon need the GBM. The static time period is preset as part of budget allocation. Furthermore, according to still another aspect of the present invention, the look-ahead mechanism includes a dynamic time period, which enables the MIT to indicate to the scheduler a period of time that the MIT will not need the GBM upon reclaiming the GBM. In the case of the dynamic time period, the MIT can include this value in a message releasing the GBM or alternatively in a message reclaiming the GBM. Other aspects of the present invention will become apparent to those of skill in the art upon a review of the detailed description in light of the following drawings.

FIG 1 depicts an exemplary embodiment of a method for controlling multiple tasks in a system according to one aspect of the present invention. FIG 2 depicts an exemplary embodiment of an apparatus for controlling a first task within an operating system, which first task has been assigned a higher level of importance than a second task within the operating system according to another aspect of the present invention. FIGs 3 -4 depict an exemplary embodiment of a method for controlling two or more tasks of a multi-task process according to yet another aspect of the present invention. FIG 5 depicts an exemplary embodiment of an operating system according to still another aspect of the present invention. FIG 6 depicts non-graceful quality degradation with overshoot of LIT. FIG 7 depicts a time-line with a budget-provision and an instantaneous budget transfer from the LIT back to the MIT.

It is worthy to note that any reference herein to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment. In certain situations, a MIT may need its GBM instantaneously when it encounters a sudden increase in load. The prior mechanisms therefore both allow for an immediate withdrawal of the CGBM back from the LIT and instantaneous provision of the GBM to the MIT. An instantaneous budget transfer may, however, result in non-graceful quality degradation with overshoot for the LIT (see FIG 6). The reason for this non-graceful quality degradation with overshoot is twofold. Firstly, in order to be able to provide the GBM instantaneously, the withdrawal of the CGBM can occur in the midst of the provision of the CGBM (see the example given below). Table 1 describes the budgets allocated to the MIT, LIT, and OIT (other important task). An MIGB of 2 and in addition a GBM of 1 is allocated to the MIT, with a period of 5. An LIGB of 3 and in addition a CGBM of 2 is allocated to the LIT, with a period of 10. An OIGB of 1 is allocated to the OIT, with a period of 12. We assume fixed-priority preemptive scheduling (FPPS) of the budgets, and an "in-the-place-of implementation of CGBs. U.S. Patent Application No. [attorney docket no. PHNL010828EPP] discloses "in-the-place-of implementation of CGBs, which is hereby incorporated by reference as if repeated herein in its entirety. Example: withdrawal of the CGBM in the midst of its provision. Table 1 : Budgets allocated to tasks.

Now consider FIG 7, showing a time-line with a budget-provision, where the guaranteed budgets MIGB, LIGB, and OIGB are released simultaneously. The MIGBs have been numbered for ease of reference. It is assumed that the

MIT has released its GBM before that simultaneous release. The LIT is therefore allowed to consume a first unit of its CGBM "in-the-place-of the GBM immediately after the MIT has completed its consumption of the GB identified with 1. The MIT re-claims its GBM during the consumption of the MIGB identified with 2. The GBM is provided instantaneously to the MIT, and, correspondingly, the CGBM is withdrawn instantaneously from the LIT. As a consequence, the LIT received only half of the CGBM during that period, and the CGBM is withdrawn in the midst of the provision. In such a situation, a LIT will typically loose its CGBM while processing a unit of work. The operational quality level at which that unit of work is processed is therefore still based on the assumed provision of the CGBM. Secondly, even when the LIT is informed before the CGBM is actually withdrawn, it may still not be able to facilitate a smooth quality reduction, i.e., to adapt its quality gracefully and without an overshoot. As an example, consider the case where a LIT is processing an MPEG-2 stream with a group of pictures (GoP) of the form IB1B2PB3B4. Decoding such a GoP requires that the P-frame is processed before any of those B-frames can be decoded. Though processed later, Bl and B2 are rendered (e.g., presented at a screen) before P. Hence, when the CGBM is withdrawn after the LIT has processed the P- frame, the LIT still needs to process all B-frames of that GoP, i.e., including Bl and B2. As a consequence, Bl and B2 will be processed at a lower operational quality level than P, and presented earlier. Such a fluctuation in quality may be perceived as a lower quality than a situation where P is also processed at a lower operational quality. A smooth quality reduction can be assured if and only if a mode change protocol is executed. For this situation, the LIT should first be allowed to smoothly reduce its quality level to a new (lower) level, and only then the CGBM should be withdrawn. A non-graceful quality degradation with overshoot of the LIT is preferred above a temporary quality dip of the MIT. The prior efforts are based on the assumption that the MIT needs its GBM instantaneously, and therefore aim at facilitating an immediate withdrawal of the CGBM from the LIT. In this section, we will consider situations where the MIT does not need its GBM instantaneously. In such situations, there is also no need for an immediate withdrawal of the CGBM from the LIT. In this section, we first reconsider the needs of an MIT, subsequently the resulting opportunities for an LIT, and finally the implications for the system. There exist situations where an MIT does not need its GBM instantaneously, as illustrated by the following examples. Early load increase detection: A controller of a scalable algorithm may be able to detect a load increase sufficiently early to not only take precautionary measures to prevent the perception of the quality reduction, but also to announce the upcoming need for the GBM timely. Scene (or shot) changes: The human eye is insensitive to scene (or shot) changes. Moreover, a system may contain means to analyze an MPEG-2 stream and to detect a scene (or shot) change. Hence, when (a) the load increase is caused by a scene change, (b) the scene change is detected, (c) the MIT is (made) aware of the fact that the load increased is caused by the scene change, the MIT may temporarily process the data at a lower operational quality level and announce the upcoming need for the GBM. Load increase announcement: A data stream may contain additional data announcing an upcoming load increase. Although standards like MPEG-2 do not define load increase announcements, they do allow the incorporation of such data. Hence, a coded media stream may be enhanced by adding information that can be used at the decoder-side to control dynamic scalable media processing. In such a situation, a MIT may also announce the need for its GBM. In all these examples, the LIT can be informed about the upcoming withdrawal of the CGBM, and the LIT may therefore choose an appropriate strategy to reduce the quality as gracefully as possible given the circumstances. Hence, when a "full-fledged" mode change protocol cannot be facilitated, there may be enough lead-time available to the LIT to reduce its quality level gracefully. According to one aspect of the present invention, the MIT announces the need for its GBM timely, which is an intermediate solution between the extremes of an instantaneous budget transfer and a full-fledged mode change protocol. There are now a number of conceivable options, depending on the moment in time that the minimal amount of "elapse" time between the detection by the MIT of the need for the GBM (and therefore the announcement about the CGBM withdrawal to the LIT) and the actual need is or becomes known: allocation-time information on delayed needs of MIT: The (minimal) amount of "elapse" time may be known statically, i.e., at the time the GMB and CGMB are allocated to the MIT and the LIT. dynamic information on delayed needs of MIT: Additional information on the (minimal) amount of "elapse" time may become available at the time the GBM is released by the MIT and/or when the MIT re-claims the GBM. The following constraints hold for the various "elapse" times: between allocated time and release time: the amount of "elapse" time passed as information by the MIT when it releases the GBM should at least be the amount specified at allocation time, and ^• between release time and re-claim time: the amount of "elapse" time passed as information when the MIT re-claims the GBM should at least be the amount passed when the MIT released the GBM. When the LIT is informed about this (minimum) amount of "elapse" time, it may take precautionary measures to facilitate an appropriate quality reduction. Note that an initial measure may be selected at allocation time, and subsequently adapted when the LIT receives the CGBM (based on information provided by the MIT when it releases the GBM), and adapted once again when the LIT is informed about the withdrawal of the CGBM (based on information provided by the MIT when it reclaims the GBM). There are three implications for the system. Firstly, we need to extend the information about a MIT: the data associated with a MIT must be extended with the information about the minimal amount of "elapse" time for usage at budget allocation time. Secondly, we have to extend the additional interfaces with the elapse-time. MIT interface (unchanged): Set_budgets( in MIGB_value: budget_type; in GBM value: budget_type);

//called by AM. Extended additional LIT interface: Set_budgets( in LIGB_value: budget_type; in CGBM_value: budget_type; in elapse_time: time); //called by AM. CGBM_available( in elapse_time: time); //called by scheduler. CGBM_not_available(in elapse_time: time); //called by scheduler.

Extended additional scheduler interface: GBM_required(in tid: task_id; in elapse_time: time); //called by MIT. GBM_not_required(in tid: task_id; in elapse_time: time); //called by MIT. Finally, when it is known that an MIT never needs its GBM instantaneously, we may come-up with alternative designs and corresponding implementations that differ significantly from the prior work. Turning to FIG 1, shown therein is a flow chart of an exemplary embodiment 10 of a method for controlling two tasks in a system. In step 11, a first of the two tasks is assigned to be a more important task (MIT). In step 12, the second of the two tasks is assigned to be a less important task (LIT). In step 13, a Guaranteed Budget Margin (GBM) is allocated to the MIT along with a More Important Guaranteed Budget (MIGB). In step 14, Conditionally Guaranteed Budget Margin (CGBM) is allocated to the LIT along with a Less Important Guaranteed Budget (LIGB). In step 15, a static period of time is allocated between when the MIT may determine it needs the GBM and the MIT actually needs the GBM. In Step 15a, the MIGB and GBM are provided to the MIT and the LIGB is provided to the LIT. In step 16, the MIT determined it no longer requires its GBM and sends a message to that effect along with a dynamic time period that the MIT can wait when it next reclaims the GBM. The italic part of the text in steps 16 and 18 are alternatives to each other. If in step 16, the MIT sends the dynamic time period then the dynamic time period is not sent in step 18, and vice versus. Alternatively, two different dynamic time periods may be sent - one at time of releasing of the GBM and another at the time of reclaiming the GBM depending upon the implementation and the amount of time that has passed between the release of the GBM and the reclaiming of the GBM as significant events may have occurred in this timeframe. In step 17, the GBM is no longer provided to the MIT, and the Conditionally Guaranteed Budget Margin (CGBM) is provided to the LIT. Moreover, the LIT is informed about the provision of the CGBM along with the static or dynamic time period, whichever is longer. In step 18, the MIT now determines it requires its GBM and sends a message to that effect along with a dynamic time period that the MIT can wait before receiving the GBM. In step 19, the LIT is explicitly informed that the CGBM will be withdrawn. Implicitly, the LIT knows that this will occur at least after the expiration of the static time period (less some processing delay from the time the MIT informed the scheduler and the scheduler informed the LIT). Moreover, the LIT may be informed at the same time as to a time period (i.e., the dynamic time period) that is longer than the static time period after which the CGBM will be withdrawn. In step 191, the CGBM is withdrawn from the LIT and the GBM is assigned to the MIT only after expiration of the static time period or dynamic time period as measured from when the determination that the MIT now requires the GBM occurred, whichever is longer. FIG 2 shows an exemplary embodiment of the roles and the interactions of the various processes described in FIGs I and 3-5. An application manager 21 is included to assign relative importance levels among the various tasks 24, 25 to be performed by the operating system 20. According to one aspect of the present invention, the application manager explicitly informs the first task 24 about a first importance level (1 1) and the second task about a second importance level (12). The first importance level is higher than the second importance level. The first task 24 is called a More Important Task. This higher importance task 24 can include either a task external to the operating system 20 or internal to the operating system 20. A second task 25 has a second importance level lower than the first importance level. This lower important task (or Less Important Task) 25 can include either a task external to the operating system 20 or internal to the operating system 20. Moreover, the second task 25 is merely lower in importance than the first task 24, but could even be the second most important task to be executed. An allocation mechanism 22 is included to allocate budgets of resources among the various tasks 24, 25 to be performed by the operating system 20. According to one aspect of the present invention, the application manager 21 explicitly informs the allocation mechanism about the relative importance levels of the tasks 24, 25 (1 1 and 12). According to yet another aspect of the present invention, the allocation mechanism 22 explicitly informs the first task 24 about a More Important Guaranteed Budget (MIGB) and a Guaranteed Budget Margin (GBM). The More Important Guaranteed Budget is the amount of resources or other limited availability items set aside for use by the first task 24. The Guaranteed Budget Margin is the amount of resources or other limited availability items set aside for use by the first task 24 above and beyond the More Important Guaranteed Budget in case needed by the first task 24. The allocation mechanism 22 also explicitly informs the second task 25 about a Less Important Guaranteed Budget (LIGB) and a Conditionally Guaranteed Budget Margin (CGBM) 14, and the static time period that task 24 can wait after it claimed the GBM before needing it (15). The Less Important Guaranteed Budget (LIGB) is the amount of resources or other limited availability items set aside for use by the second or lower priority task 25. According to yet another aspect of the present invention, the allocation mechanism 22 explicitly informs the scheduler 23 about the budgets allocated to the tasks 24, 25 (13 and 14) and the static time period that task 24 can wait after it claimed the Guaranteed Budget Margin before needing it (15). A scheduler 23 controls provisioning of the budgeted amounts of resources to the various tasks 24, 25 to be performed by the operating system 20, including the first task 24 and the second task 25. The scheduler 23 provides the More Important Guaranteed Budget plus the Guaranteed Budget Margin to the first task 24 at a first possible occasion (15a). The scheduler also provides the Less Important Guaranteed Budget to the second task 25 at a first possible occasion (15a). If the first task 24 determines at some point during execution that the first task 24 can execute properly with the More Important Guaranteed Budget only, the first task 24 explicitly informs the scheduler 23 that the first task 24 does not require its Guaranteed Budget Margin (16). The first task 24 may also inform the scheduler 23 of a dynamic time period that the first task 24 can wait when next reclaiming the GBM (16). In this case, the scheduler 23 stops providing the Guaranteed Budget Margin to the first task 24 at a first possible occasion and starts providing the Conditionally Guaranteed Budget Margin to the second task 25 at a first possible occasion. After this, the scheduler 23 informs the second task 25 of the granting of the Conditionally Guaranteed Budget Margin including the time period (static or dynamic, whichever is longer) between the notification of the withdrawal and the actual withdrawal of the Conditionally Guaranteed Budget margin (17). The second task 25 now knows that it will have the CGBM for at least a predetermined static (or dynamic when longer) time period because the second task knows it will be informed of a withdrawal of the CGBM before actually withdrawing of the CGBM begins and that the time period between the informing of the withdrawal and the actual withdrawal will be at least as long (it may even be longer in some circumstances) as the predetermined static time period (or dynamic when longer). The Conditionally Guaranteed Budget Margin is the amount of resources or other limited availability items set aside for use by the second task 25 above and beyond the Less Important Guaranteed Budget in case needed by the second task 25, but which amount is only provided when not needed elsewhere, such as by the higher importance or More Important Task 24. Subsequently, the first task 24 may determine at some point during execution that the first task 24 requires the Guaranteed Budget Margin as well, in which case the first task 24 explicitly informs the scheduler 23 that the first task 24 does require its Guaranteed Budget Margin (18). At this point, the first task 24 may also inform the scheduler 23 that it can wait for a dynamic time period when next reclaiming the GBM before actually receiving the GBM, which dynamic time period may be longer than the predetermined static time period. The scheduler 23 then informs the second task 25 that the Conditionally Guaranteed Budget Margin will be withdrawn (after the longer of the dynamic or static time periods) (19). The scheduler 23 then stops providing the Conditionally Guaranteed Budget Margin to the second task 23 after expiration of the longer of the static or dynamic time periods and the scheduler 23 starts providing the Guaranteed Budget Margin to the first task 24 after expiration of the static or dynamic time periods (191). An application manager 21 assigns and de-assigns the MIT role to a given task. The application manager also assigns and de-assigns the LIT role to another given task. The application manager 21 then becomes inactive while the allocation mechanism 22 becomes active. When the MIT and LIT roles expire, the application manager 21 becomes active again, while the allocation mechanism 22 becomes inactive. The allocation mechanism 22 allocates the MIGB and the GBM to the MIT and explicitly informs the MIT of these allocations. The allocation mechanism 22 also allocates the LIGB and the CGBM to the LIT and explicitly informs the LIT of these allocations. The allocation mechanism 22 sends the reservation to the scheduler 23, which activates the scheduler process, which executes to completion. The scheduler 23 accepts reservation commands for the LIT and the MIT from the allocation mechanism; grants the MIGB and GBM to the MIT; and also grants the LIGB to the LIT. The scheduler then runs in accordance with a scheduling algorithm. The scheduler 23 receives a message from the MIT that the MIT no longer requires the GBM. The scheduler then grants only the MIGB to the MIT, informs the LIT of the budget increase, and grants the LIGB and the CGBM to the LIT. The scheduler 23 may subsequently receive a message from the MIT that the MIT now requires its GBM, in which case the scheduler 23 informs the LIT of the budget decrease. More details concerning the interaction of the various processes can be found in U.S. Patent Application No. [attorney docket no, 613652], which is hereby incorporated by reference as if repeated herein in its entirety, including the drawings. Turning to FIGs 3-4, shown therein is a flow chart of an exemplary embodiment 30 of a method for controlling two tasks in a multitask system. In step 31, a first task that is a more important task is explicitly informed about a More Important Guaranteed Budget and a Guaranteed Budget Margin. In step 32, a second task that is a less important task is explicitly informed about a Less Important Guaranteed Budget, a Conditionally Guaranteed Budget Margin and a static time period for which withdrawal of the Conditionally Guaranteed Budget Margin will be delayed upon notification of withdrawal. In step 33, the More Important Guaranteed Budget plus the Guaranteed Budget Margin is provided to the first task at a first possible occasion. In step 34, the Less Important Guaranteed Budget is provided to the second task at a first possible occasion. In step 35, upon the first task determining at some point during execution that the first task can do its job with the More Important Guaranteed Budget only, a scheduler is explicitly informed that the first task does not require its Guaranteed Budget Margin along with a dynamic time period that the first task will wait when subsequently reclaiming the Guaranteed Budget Margin before actually requiring the Guaranteed Budget Margin. In step 36, the Guaranteed Budget Margin is no longer provided to the first task at a first possible occasion.

In step 41, the Conditionally Guaranteed Budget Margin is provided to the second task at a first possible occasion. In step 42, the second task is informed of the providing the Conditionally Guaranteed Budget Margin, including information describing the delay between notification of withdrawal of the Conditionally Guaranteed Budget Margin and the actual withdrawal. In step 43, the first task determines at some point during execution that the first task requires the Guaranteed Budget Margin as well. In step 44, the scheduler is explicitly informed that the first task does require its Guaranteed Budget Margin along with a dynamic time period that the first task can wait before receiving the Guaranteed Budget Margin. In step 45, the second task is informed that the Conditionally Guaranteed Budget Margin will be withdrawn after a predetermined static time period or dynamic time period, whichever is longer. In step 46, the Conditionally Guaranteed Budget Margin is no longer being provided to the second task after expiration of the static or dynamic time period, which ever is longer. In step 47, the Guaranteed Budget Margin is provided to the first task. Turning to FIG 5, shown therein is a time flow of an exemplary embodiment 50 of a method for controlling multiple processes according to yet another aspect of the present invention. The exact order of the processes set forth in FIG 5 is not significant, however, the order in time is important relative to some processes, which will be indicated when discussing these processes. Where not so indicated, the relative order could be varied. Upon start 51, the following process can occur for a two-process system. A similar process would occur for a three-process system, in which case the interaction would be similar between any two processes in the hierarchy. First, the relative importance must be established. The allocation mechanism or some other process assigns the levels of importance to the two tasks. One of these tasks is assigned to be the More Important Task 52, in which case the allocation mechanism may inform this process of its importance designation. The other of these tasks is assigned to be the Less Important Task 54, in which case the allocation mechanism may inform this process of its importance designation. The order in which the tasks are assigned importance levels is not necessarily important. For example, the lower importance task could be assigned first, hence element 54 could occur prior to element 52. Once the relative importances are assigned, each of the tasks is explicitly informed of its budget. For example, the allocation mechanism explicitly informs the MIT about the More Important Guaranteed Budget and the Guaranteed Budget Margin 53. The allocation mechanism also explicitly informs the LIT about the Less Important Guaranteed Budget 55 and the Conditionally Guaranteed Budget Margin. Moreover, the information of the CGBM includes the (static) elapse time for which the LIT can expect to have the CGBM. The order of processes 53 and 55 is not important other than each of them must occur after assignment of the relative importance levels. Moreover, the informing of MIT budgets can occur immediately after the assignment of the MIT or after all importance levels have been assigned. The informing of the LIT budget can occur before or after the informing of the MIT budget. The only requirement is that the informing of the budgets can only occur after assignment of the relative importance levels. After informing the MIT about its budget, the scheduler provides the More Important Guaranteed Budget plus the Guaranteed Budget Margin to the MIT at the first possible occasion 56. This provisioning of the MIT budget can occur before or after the informing the LIT about the Less Important Guaranteed Budget, and might even occur as early as immediately following the informing of MIT budgets to enable the MIT to begin using the MIT budget upon being so informed. Subsequent to provisioning the MIT budget, the scheduler provides the Less Important Guaranteed Budget to the LIT at the first possible occasion 57. This will normally occur after the provisioning of the MIT budget due to the relative importance levels of the two tasks, but could occur as early as following the informing of the LIT budgets to enable the LIT to begin using the LIT budget upon being so informed. At some point during execution, the MIT may observe that it can do its job with its More Important Guaranteed Budget only, in which case the MIT informs the scheduler of this observation along with the dynamic delay time 58. The dynamic delay time is the time that the MIT can wait upon reclaiming the GBM before actually receiving the GBM. This step 58 can only occur after provisioning of the MIT budgets, but could occur at any point thereafter in the budget period. For simplicity purposes, the observation and the informing of the scheduler are shown as a single element, but they could be separated in time. Once informed about the MIT's observation, the scheduler stops providing the Guaranteed Budget Margin to the MIT at the first possible occasion 59. This most likely will occur immediately following receipt of the information by the scheduler to enable use of the Guaranteed Budget Margin as early as possible. Once this condition (i.e., that the MIT does not require the Guaranteed Budget Margin) is determined to exist by the MIT, the system should make use of the Guaranteed Budget Margin as quickly as possible because this condition may not exist forever (or at least for the remainder of the budget period). At this time, the MIT may also inform the scheduler as to a dynamic time period that the MIT is willing to wait before receiving the GBM when next reclaiming the GBM. Subsequent to stopping providing the Guaranteed Budget Margin to the MIT 59, the scheduler starts providing the Conditionally Guaranteed Budget Margin to the LIT at the first possible occasion 60. The scheduler then informs the LIT of this additional budget provision 61 along with the static or dynamic time period (whichever is longer) that the LIT can at least expect to have the LIGB. Preferably this informing 61 should occur after provisioning of the Conditionally Guaranteed Budget Margin 60 so that the LIT can begin using the extra budget without delay, however, in some situations these two elements 60, 61 may occur in different order. The scheduler also informs the LIT as to a time period (either static or dynamic, whichever is longer) that the MIT is willing to wait before receiving the GBM when next reclaiming the GBM. At some point during execution in the same budget period, the MIT may observe that it now requires its Guaranteed Budget Margin as well 62. This can occur at any time after element 58, and depending when thereafter some of the elements (i.e., 59, 60 and 61) may be affected. After this new determination, the MIT explicitly informs the scheduler that it does require its Guaranteed Budget Margin 62. As before, these two sub-steps may occur separated in time, however for simplicity purposes they are shown as a single element. This message reclaiming the Guaranteed Budget Margin may include a dynamic time period that the MIT is willing to wait before receiving the GBM. The hatched box represents the static time period from which the LIT is informed that it will lose the CGBM and the CGBM is actually withdrawn. This static time period could also be measured from the moment the MIT informs the scheduler that it needs the GBM (or from the moment this determination is made by the MIT) to the moment the GBM is provided to the MIT. The exact start and stop of this period is not significant, as the delays between messages may be small. The significant point is that a predetermined static time period is known and the various processes can rely upon this static time period, and therefore by definition each knows from what point or activity the static time period is initiated and ends. After receiving this information, the scheduler informs the LIT that Conditionally Guaranteed Budget Margin will be withdrawn 63 after predetermined static time period (either known then to the LIT or now informed as to the length of this time). Alternatively, the LIT may be informed of another time period (the dynamic time period) longer than the static time period that the LIT will have the CGBM before it is removed. Typically, this should occur before the scheduler stops providing this budget margin to the LIT to prevent improper use of resources and to enable the LIT to adjust accordingly and enable a smooth transition. The scheduler then stops providing the Conditionally Guaranteed Budget Margin to the LIT after expiration of the dynamic or static time period, whichever is longer 64. The scheduler then starts providing the Guaranteed Budget Margin to the MIT after expiration of the longer of the static or dynamic time period 65. The scheduler should first stop providing the extra budget to the LIT before providing the MIT with the extra budget to prevent improper use of resources and to enable a smooth transition. At some point in time, the process ends 66; however, several other iterations of the elements 58-65 could occur depending upon application specifics. Moreover, the MIT may never determine it does not need the Guaranteed Budget Margin 58, or the MIT may never determine it needs the Guaranteed Budget Margin 62 after determining it does not need the Guaranteed Budget Margin 58. We have shown that the requirement of an instantaneous budget transfer (i.e., an immediate withdrawal of the CGBM from the LIT and instantaneous provision of the GBM to the MIT) is too stringent in many situations. We have generalized the prior approaches by describing extensions of both the method and the system for CGBs. Application of the inventions herein becomes traceable due to the extensions of the additional interfaces. Although various embodiments are specifically illustrated and described herein, it will be appreciated that modifications and variations of the invention are covered by the above teachings and are within the purview of the appended claims without departing from the spirit and intended scope of the invention. For example, certain terms and protocols are employed, however, other names and protocols could be used without departing from the scope of the present invention. Furthermore, this example should not be interpreted to limit the modifications and variations of the invention that are covered by the claims but is merely illustrative of possible variations.

Claims

CLAIMS:

1. A method (10) for controlling multiple tasks in system comprising: assigning a first task to be a More Important Task (1 1); assigning a second task to be a Less Important Task (12); allocating a Guaranteed Budget Margin to the More Important Task along with a More Important Guaranteed Budget (13); allocating a Less Important Guaranteed Budget to the Less Important Task along with a Conditionally Guaranteed Budget Margin (14); allocating a static period of time between when the More Important Task may determine it needs the Guaranteed Budget Margin and the More Important Task actually needs the Guaranteed Budget Margin (15); providing the More Important Guaranteed Budget and the Guaranteed Budget Margin to the More Important Task, and the Less Important Guaranteed Budget to the Less Important Task at a first possible occasion (15a); determining by the More Important Task that the More Important Task no longer requires the Guaranteed Budget Margin (16); stopping to provide the Guaranteed Budget Margin to the MIT and starting to provide a Conditionally Guaranteed Budget Margin to the Less Important Task, and explicitly informing the Less Important Task about the provision of the Conditionally Guaranteed Budget (17); determining by the More Important Task that the More Important Task now requires the Guaranteed Budget Margin (18); explicitly informing the Less Important Task that the Conditionally Guaranteed Budget Margin will be withdrawn (19); and withdrawing the Conditionally Guaranteed Budget Margin from the Less Important Task and assigning the Guaranteed Budget Margin to the More Important Task only after expiration of the static time period as measured from when the determination that the More Important Task now requires the Guaranteed Budget Margin occurred (191).

2. The method (10) according to claim 1, further comprising: informing the scheduler when releasing the Guaranteed Budget Margin as to a dynamic period of time that the More Important Task can wait when next reclaiming the Guaranteed Budget Margin (16).

3. The method (10) according to claim 2, further comprising: withdrawing the Conditionally Guaranteed Budget Margin from the Less Important Task and assigning the Guaranteed Budget Margin to the More Important Task only after expiration of the static time period or dynamic time period, whichever is longer, as measured from when the determination that the More Important Task now requires the Guaranteed Budget Margin occurred (191).

4. The method (10) according to claim 1 , further comprising: informing the scheduler as to a dynamic period of time that the More Important Task can wait before receiving the Guaranteed Budget Margin upon reclaiming the Guaranteed Budget Margin (18).

5. The method (10) according to claim 4, further comprising: withdrawing the Conditionally Guaranteed Budget Margin from the Less Important Task and assigning the Guaranteed Budget Margin to the More Important Task only after expiration of either the static time period or the dynamic time period, whichever is longer, as measured from when the determination that the More Important Task now requires the Guaranteed Budget Margin occurred (191).

6. The method (10) according to claim 1, wherein said explicitly informing the Less Important Task about the provision of the Conditionally Guaranteed Budget Margin further comprises informing the Less Important Task about the static time period for which a potential forthcoming withdrawal will be delayed (17).

7. The method (10) according to claim 1 , wherein said explicitly informing the Less Important Task that the Conditionally Guaranteed Budget Margin will be withdrawn further comprises explicitly informing the Less Important Task about the static time period for which the withdrawal will be delayed (19).

8. The method according to claim 1, further comprising informing the Less Important Task of the static time period (17).

9. A method (30) for controlling two or more tasks of a multi-task system comprising: explicitly informing a first task that is a more important task about a More Important Guaranteed Budget and a Guaranteed Budget Margin (31); explicitly informing a second task that is a less important task about a Less Important Guaranteed Budget, a Conditionally Guaranteed Budget Margin and a static time period for which withdrawal of the Conditionally Guaranteed Budget Margin will be delayed upon notification of withdrawal (32); providing the More Important Guaranteed Budget plus the Guaranteed Budget Margin to the first task at a first possible occasion (33); providing the Less Important Guaranteed Budget to the second task at a first possible occasion (34); upon the first task determining at some point during execution that the first task can do its job with the More Important Guaranteed Budget only, explicitly informing a scheduler that the first task does not require its Guaranteed Budget Margin along with a dynamic time period that the first task will wait when subsequently reclaiming the Guaranteed Budget Margin before actually requiring the Guaranteed Budget Margin (35).

10. The method (30) according to claim 9, further comprising: stopping to provide the Guaranteed Budget Margin to the first task at a first possible occasion (36).

1 1. The method (30) according to claim 10, further comprising: starting to provide the Conditionally Guaranteed Budget Margin to the second task at a first possible occasion (41).

12. The method (30) according to claim 1 1, further comprising: informing the second task of the providing the Conditionally Guaranteed Budget

Margin along with a static time period or a dynamic time period for which subsequent withdrawal of the Conditionally Guaranteed Budget Margin will be delayed upon notification of withdrawal (42).

13. The method (30) according to claim 1 1, further comprising: determining by the first task at some point during execution that the first task requires the Guaranteed Budget Margin as well (43).

14. The method (30) according to claim 13, further comprising: explicitly informing the scheduler that the first task does require its Guaranteed Budget Margin along with a dynamic time period that the first task can wait before receiving the Guaranteed Budget Margin (44).

15. The method (30) according to claim 14, further comprising: informing the second task that the Conditionally Guaranteed Budget Margin will be withdrawn after a predetermined static time period or dynamic time period, whichever is longer (45).

16. The method (30) according to claim 15, further comprising: stopping to provide the Conditionally Guaranteed Budget Margin to the second task after expiration of the static or dynamic time period, whichever is longer (46).

17. The method (30) according to claim 15, further comprising: starting to provide the Guaranteed Budget Margin to the first task after expiration of the static or dynamic time period, whichever is longer (47).

18. An apparatus (20) comprising: a first task (24) having a first importance level; a second task (25) having a second importance level lower than the first importance level; an allocation mechanism (22) to allocate budgets of resources, said allocation mechanism (22) explicitly informing the first (24) task about a More Important Guaranteed Budget and a Guaranteed Budget Margin and explicitly informing the second task (25) about a Less Important Guaranteed Budget, a Conditionally Guaranteed Budget Margin and a predetermined static time period for which withdrawal of the Conditionally Guaranteed Budget Margin will be delayed upon notification of withdrawal; and a scheduler (23) providing the budgeted amounts to the first and second tasks (24, 25), said scheduler (23) providing the More Important Guaranteed Budget plus the Guaranteed Budget Margin to the first task (24) at a first possible occasion and providing the Less Important Guaranteed Budget to the second task (25) at a first possible occasion, wherein upon the first task (24) determining at some point during execution that the first task (24) can execute properly with the More Important Guaranteed Budget only, said first task (24) explicitly informing the scheduler (23) that the first task (24) does not require its Guaranteed Budget Margin; wherein the scheduler (23) stops providing the Guaranteed Budget Margin to the first task (24) at a first possible occasion and starts providing the Conditionally Guaranteed Budget Margin to the second task (25) at a first possible occasion. wherein the scheduler (23) informs the second task (25) of the providing the Conditionally Guaranteed Budget Margin; wherein the first task (24) determines at some point during execution that the first task requires the Guaranteed Budget Margin as well and the first task explicitly informs the scheduler (23) that the first task (24) does require its Guaranteed Budget Margin; wherein the scheduler (23) informs the second task (25) that the Conditionally Guaranteed Budget Margin will be withdrawn; and wherein the scheduler (23) stops providing the Conditionally Guaranteed Budget Margin to the second task (25) after expiration of the predetermined static time period.

19. The apparatus (20) according to claim 18, wherein the scheduler (23) starts providing the Guaranteed Budget Margin to the first task (24) after expiration of the predetermined static time period.

20. The apparatus (20) according to claim 18, wherein when the first task (24) informs the scheduler (23) that the first task does (24) not require the Guaranteed Budget Margin, the first task (24) also informs the scheduler (23) as to a dynamic time period that the first task (24) can wait when reclaiming the Guaranteed Budget Margin, and when the first task (24) subsequently reclaims the Guaranteed Budget Margin, the scheduler (23) stops providing the Conditionally Guaranteed Budget Margin to the second task (25) after expiration of a predetermined static time period or the dynamic time period, whichever is longer.

21. The apparatus (20) according to claim 18, wherein when the first task (24) informs the scheduler (23) that the first task (24) now requires the Guaranteed Budget Margin, the first task (24) also informs the scheduler (23) as to a dynamic time period that the first task (24) can wait before receiving the Guaranteed Budget Margin and the scheduler (23) stops providing the Conditionally Guaranteed Budget Margin to the second task (25) after expiration of a predetermined static time period or the dynamic time period, whichever is longer.