WO2005073853A2

WO2005073853A2 - Method of and system for handling deferred execution

Info

Publication number: WO2005073853A2
Application number: PCT/IB2005/050187
Authority: WO
Inventors: Reinder J. Bril; Clara M. Otero Perez
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2004-01-30
Filing date: 2005-01-17
Publication date: 2005-08-11
Also published as: WO2005073853A3

Abstract

There is provided a method of handling deferred execution in a computer system (10). The system (10) concurrently executes resource consuming entities. The system (10) includes a computing resource scheduler for allocating computing resources between the entities. Moreover, the scheduler includes a list of data structures corresponding to blocked entities. The scheduler determines for a first entity blocked by one or more second entities a blocking time instance at which the first entity is blocked, and a pre-emption time corresponding to execution time of the one or more second consuming entities. Additionally, the scheduler determines from a measure of present time, the blocking time and the preemption time remaining an available executing time for the first entity. Thus, the scheduler can direct the first entity to execute during the remaining executing time and thereby achieve more efficient computing resource budget allocation.

Description

Method of and system for handling deferred execution

The present invention relates to methods of handling deferred execution, for example to circumvent blocking problems giving rise to deferred execution in multitasking computer systems. Moreover, the present invention also relates to systems implementing the methods.

Multitasking computer systems are well known and include devices such as personal computers as well as more dedicated audio-visual equipment including processors for processing audio-visual content in real-time. For example, in a United States patent no. US 6, 108, 683, there is described a computer system including a central processing unit (CPU) for executing a software operating system. The operating system is arranged to support a real-time class processor scheduler for use in implementing multi-media processing in the CPU, the scheduler being a fixed priority process scheduler. The scheduler is operable to allocate CPU time to a given user process whilst simultaneously providing a blocking detection process. When the given user process is blocked due to input/output waiting, the process scheduler allocates CPU time to the blocking detection process. The blocking detection process is operable to detect an occurrence of blocking and to notify such occurrence of blocking to the scheduler. Subsequently, the scheduler recognizes that the execution of the given user process is halted and proceeds to enable one or more other user processes to be executed. Moreover, the process scheduler is notified when the state of the given user process is changed into a ready or executable state indicating that the given user process is able to execute. When the scheduler receives this notification, the scheduler allocates CPU time to the given user process again; in other words, if the scheduler allows deferred execution, then other processes are potentially susceptible to missing deadlines. The inventors have appreciated that it is feasible to provide an enhanced method of handling a blocking state by including an additional step of preventing the given task resuming running after the notification for a defined period of time so that other concurrently running processes do not miss their deadlines; such an enhanced method is concerned with more effective allocation of resource budgets. However, in many circumstances, the inventors have envisaged that simply withdrawing CPU resources from the given user process for the period of time is not appropriate. For example, a CPU of a computer system is capable of being arranged to execute a software application functioning as an MPEG image decoder. The software application is susceptible to blocking when awaiting data from a co-processor such as a variable length decoder (VLD). Many similar situations exist where a software application executing on a processor blocks due to lack of data from a hardware device. The inventors have devised an alternative method for at least partially coping with such situations. Techniques for coping with blocking are already known. For example, in a published United States patent application no. US2003/0101084, there is described media processing executed using software in consumer terminals such as digital television sets or set-top boxes. For reasons of cost effectiveness, average processor utilization must be high. Such high utilization is mostly achieved by allocating below worst-case processor budgets to tasks performing media processing operations. Only if a stable output quality is a primary requirement, is a task allocated a worst-case processor budget. To gain back on cost- effectiveness in such a situation, there is disclosed a method and system operable to reallocate an unused part of a budget from a first task τ_m with a worst-case budget to a second task τ_p with a below worst-case budget. The second task τ_p is then capable using the resulting budget surplus to improve the quality of its output. Moreover, the method and system described operate at a very low level with regard to scheduling of the tasks performing the media processing. What effectively happens is that the second task τ_p is executed in place of the first task τ_m as if it were the first task τ_m, with scheduling characteristics such as period and priority of the first task τ_m. Thus, the inventors have devised a yet further enhanced method for coping with blocking, the method at least partially addressing problems arising in known arrangements as described in the foregoing.

An object of the invention is to provide an improved method of scheduling processing resources in computing system executing concurrent software processes. According to a first aspect of the present invention, there is provided a method of handling deferred execution, characterized in that the method includes the steps of: (a) providing a computer system for concurrently executing resource consuming entities, each entity comprising one or more software processes and/or one or more hardware devices;

(b) arranging for the system to include resource scheduling means for allocating computing resources between the resource consuming entities;

(c) arranging for the scheduling means to include a list of data structures corresponding to those of the resource consuming entities subject to blocking;

(d) arranging for the scheduling means to determine for a first resource consuming entity that becomes blocked by one or more second resource consuming entities a blocking time instance at which the first entity is blocked, and a pre-emption time corresponding to execution time of the one or more second resource consuming entities;

(e) determining from a measure of present time, the blocking time and the preemption time remaining an available executing time for the first entity; and

(f) arranging for the scheduling means to direct the first entity to execute during the remaining executing time. The invention is of advantage in that it is capable of providing for more efficient allocation of computing resource budgets in the system when blocking of resource consuming entities arises therein. Preferably, in the method, the computer system is arranged to execute the resource consuming entities periodically, and the scheduling means is operable to replenish resource allocations including in the list at commencement of each period. Such periodical partitioning enables the system to cope with real-time computing applications where adherence to defined time deadlines is paramount. Preferably, in the method, data structures, for example RCE's, corresponding to those of the resource consuming entities that are blocked are dynamically updated as the data structures become blocked or unblocked. Dynamic updating of the data structures in the list enables the system to be highly responsive as resource consuming entities become unblocked. Preferably, in the method, computing resources becoming available in consequence of the first resource consuming entity blocking become available for executing one of more second resource consuming entities. Preferably, in the method, the scheduling means is operable to determine from the list one or more guaranteed resource budgets and one or more optional resource budgets, the one or more optional resource budgets being available for high priority resource consuming entities recorded in the list and being susceptible to being lost if not consumed within one or more given time periods. Preferably, the method further comprises a step of: (g) arranging for the scheduling means to provide a middle-band priority in which resource slack generated from higher priority resource consuming entities is made available to relatively lower priority resource consuming entities. More preferably, in the method, the resource slack is subsequently made available to higher priority resource consuming entities responsible for generating the resource slack. According to a second aspect of the present invention, there is provided a resource scheduler including resource scheduling means operable according to the method of the first aspect of the invention. According to a third aspect of the present invention, there is provided a computer system for executing resource consuming entities, each entity comprising one or more software processes, the system operable to schedule execution of the resource consuming entities according to the method of the first aspect of the invention. According to a fourth aspect of the present invention, there is provided computer resource scheduling software executable on a computer system, said software operable to implement the method according to the first aspect of the invention. It will be appreciated that features of the invention are susceptible to being combined in any combination without departing from the scope of the invention.

Embodiments of the invention will be described, by way of example only, with reference to the following diagrams wherein: Fig. 1 is an illustration of a computer system operable to execute concurrently software processes Pi to P_n; Fig. 2 is a list L of data structures representing resource consuming entities (RCE's) causing blocking to occur within the system of Fig. 1; Fig. 3 is a first temporal diagram of two RCE's Ri and R₂ executing concurrently within the system of Fig. 1 ; and Fig. 4 is a second temporal diagram of the two RCE's Ri and R₂ executing concurrently within the system when additional blocking occurs. High volume electronics (HVE) consumer systems, for example digital television (TV) sets, digitally improved analogue TV sets and set-top boxes (STBs) are required to become open and flexible while remaining cost-effective and robust, and yet have properties that are characteristic of the real-time domain. Since openness and flexibility are typical characteristics of software-based systems, significant parts of media processing implemented in HVE consumer systems are expected to become implemented in software executable concurrently with control and services which are also presently implemented using software. Consumer products are heavily resource constrained; for example, HVE systems do not employ unnecessarily fast and therefore expensive computing devices because a choice of such devices risks in manufacture rendering such HVE systems uncompetitive in comparison to comparable products from other vendors. Consequently, resources within a given HVE system have to be used very cost-effectively, whilst providing expected qualities of HVE consumer systems, such qualities including robustness as well as meeting stringent timing requirements imposed by, for example, high-quality digital audio and video processing. Concerning robustness, a user does not expect a television set whose operation is based on executing software applications to stall with a message "please reboot the system" presented to the user. A concept of allocating computing resource budgets is contemporarily known as an approach to enhance robustness of computer-based products. A significant concern for media processing in software subject to execution with regard to computing resource budgets is how to cope with blocking, namely when a temporarily halted process resumes execution and no precautionary measures are taken. One approach is simply to withdraw budget from a software process causing blocking. Such a simple approach is based on an assumption that a given process causing blocking does so because it is "ahead", namely the given process is not able:

(a) to write data to its output buffer because another process still has to consume previous data from that buffer; or

(b) to read data from its input buffer because another process still has to produce the data to be stored in that buffer.

Solutions to problems for communication and synchronization between software entities are known and are based on extensions of principles of priority inheritance and priority ceiling protocol emulations for budget or reservation functions provided on computer-based systems. Such solutions do not address where, for example, a MPEG decoder is implemented in a software entity executable on a proprietary TriMedia computing platform where the MPEG decoder software may block because it is awaiting data from a co -processor such as a variable length decoder (VLD). The present invention is directed at addressing this and similar software blocking problems. Referring to Fig. 1, there is shown a computer system 10 operable to execute concurrent software processes Pi, P₂ ..., P_n. The system 10 is arranged to allocate to the processes Pi, P₂, ... P_n corresponding processor (CPU) resource budgets Bi, B₂, ... B_n respectively. Such a set of concurrent processes sharing an overall CPU resource budget will be termed a resource consuming entity (RCE). For example, the RCE can be an MPEG decoder implemented as a software application for execution on the CPU implemented using the aforementioned proprietary TriMedia computing platform, the decoder using a coprocessor, for example a VLD, or another hardware device. Such an arrangement will, for purposes of describing embodiments of the invention, be referred to as a "MPEG RCE". In operation, when the MPEG RCE executing in the system 10 blocks awaiting data from the VLD, it is necessary to decide how the computing resource budget of the MPEG RCE should be allocated. A previous approach envisaged by the inventors of simply withdrawing resource budget from a blocking process is not appropriate as experimental investigations have shown that the MPEG process would typically lose most of its resource budget during every execution period, and would subsequently run almost entirely on slack generated by itself. In consequence, any advantage derived from employing resource budget allocations for the concurrent processes Pi, P₂, ...P_n is lost for the MPEG RCE. Other approaches are inappropriate, for example an approach as described in a publication "Resource sharing in reservation-based systems" by D. de Niz, Saowanee Saewong, R. Rajkumar and L. Abeni, Proceedings of 7^th Real-Time Technology and Applications Symposium (RTAS) pp. 130- 131, 2001 is also unsuitable; the approach described in this publication is inappropriate because it assumes RCE's executing on a single processor are arranged to share a resource in contradistinction to the example of the MPEG RCE described in the foregoing which just uses the system 10 rather than sharing the VLD with other RCE's executing on the same system 10. In devising at least a partial solution to aforementioned problems, the inventors have taken the following aspects into account:

(a) the solution proposed should not interfere with other computing resource budgets concurrently placed on computing resources of the system 10; (b) the blocking RCE needs to know how much of its budget remains after blocking in order to decide how to continue. Moreover, given that cost-effectiveness is a major issue for HVE products, the solution proposed should involve minimal computing resource overhead. In the present invention, a first aspect is a blocking interval ΔT_B, namely a time period that elapses from a first instance a given RCE, for example the aforesaid MPEG RCE, becomes blocked to a second corresponding instance where the given RCE becomes unblocked. Moreover, a second aspect concerns an accumulative pre-emption time period ΔT_E, namely a time period in which the given RCE is pre-empted in the system 10 by one or more higher priority processes, entities or hardware. Rather than withdrawing a remainder of a budget for a current time period in the system 10, only the blocking interval ΔT_B minus the accumulative pre-emption time ΔT_E, namely ΔT_B - ΔT_E, is withdrawn from a remainder of a computing resource budget offered to the given RCE for the current time period. In order to further elucidate the present invention, an implementation of the present invention will be described. In the system 10, there is provided a dedicated list L of data structures DS as depicted in Fig. 2. The list L is associated with blocked RCE's, the list L being maintained by a resource budget scheduler (BS) concurrently executing as a software process in the system 10. The list L is ordered from lowest priority LP to highest priority HP; for example, a data structure DSj describing a RCE R,- is in a higher priority ranking in the list L before a data structure DSj describing a RCE Rj when indices i, j are such that i>j. Moreover, each data structure DS includes data fields for at least one of:

(a) a start time Ts corresponding to a time instance at which its corresponding

RCE is blocked; and (b) the total pre-emption time period ΔTp of its RCE arising from other RCE's having a higher priority, for example the total pre-emption time period of the RCE R; resulting from higher priority RCE's and/or hardware;

(c) other parameters as will be elucidated later such as a corresponding optional budget O_B and a corresponding guaranteed budget Gβ. In operation of the system 10, when the RCE R, causes blocking to occur, a data structure DSj corresponding the blocking RCE R is included into the aforesaid list L. The data structure DSj is initialized with data indicative of an instance at which blocking occurred as the start time Ts, and zero for the accumulative pre-emption time period ΔT_E. The system 10 then proceeds to execute another RCE Rj instead of the blocking RCE Rj. Subsequently, the RCE Rj stops, for example on account of a context switch occurring in the system 10. When the RCE Rj executes within its allocated computing resource budget, a time period ΔT_X since it was invoked is subtracted from the resource budget allocated to the RCE Rj. Next, the following actions are performed on the data structure of the RCE R; included in the aforesaid list L:

(i) if the indices i>j, then the interval ΔTx is added to the total accumulative preemption time ΔT_E of the RCE R;; and (ii) the pre-emption times ΔT_E of other RCE's is left unchanged. Assuming next that a new execution time period starts for the RCE Rj, if the RCE Rj is not included in the aforesaid list L, its computing resource budget for the new time period is simply replenished as normal. Conversely, if the RCE R, is included in the list L, its resource budget is replenished and its data structure in the list L is updated such that the start time Ts is set to the current time T and the total accumulative pre-emption time ΔT_E is set to zero. In a situation where the RCE R; unblocks , no action is taken if the RCE R; is not in the list L; conversely, if RCE R; is in the list L, it is regarded by the system 10 as being ready earlier and the following steps are then performed: (a) the data structure DSi corresponding to the RCE R is removed from the list L; (b) the current time T minus the start time Ts minus the total accumulative preemption time ΔTp namely ΔT_A = T-Ts - ΔTp, is subtracted from the remainder of the budget allocated in the new period to the RCE R. If the time interval ΔT_A becomes negative, it is set to zero. The resulting value of the interval ΔT_A corresponds to a remaining guaranteed budget available in the current time period. It is to be noted that when a given RCE becomes available at a time instance T_R, whilst a higher priority RCE is executing, a time interval from the instance T_R to the current time T is included in the pre-emption time ΔT_E of the given RCE. Hence, the total pre-emption time ΔTp administered in the data structure DS in the list L potentially includes pre-emption time from the time instance T_R until the current time T. Thus, the time interval ΔT_A is identical to the blocking interval ΔT_B minus the pre-emption time ΔT_E during the blocking interval. Use of the aforementioned list L with its data structures corresponding to blocked RCE's is capable of providing more appropriate prioritizing of concurrently executing RCE's as will be elucidated in further detail later. A following example case will assist to elucidate a situation to which the present invention is highly pertinent. In the example case, there arises a situation where the RCE R; is blocked and another RCE Rj is concurrently executing, the resource budget of the RCE R_j has priority over the resource budget of the RCE Ri when indices j < i. In a first scenario where the indices j=i+l, no interference occurs with regard to guarantees of either higher priority HP resource budgets or lower priority LP resource budgets. Consequently, there is no need to subtract the time the RCE R, is executing from the resource budget of the RCE Rj whilst R; is blocked, thereby allowing the RCE R to consume its resource budget at a later time corresponding to deferred execution. In a second scenario where the indices j>i+l, a problem may arise when the RCE Rj is allowed to defer consumption of the blocking time of its resource budget. This problem will be elucidated with reference to Fig. 3. In Fig. 3, there are shown two RCE's, namely Ri and R₂. Both RCE's Ri and R₂ have strictly periodic computing resource budgets. The budget for the RCE Ri has a time period ΔTQI = 5 μsec, a relative deadline T_DI = 5 μsec, and an execute time period ΔT_BI = 3 μsec to execute within each period ΔTQ_I. Moreover, the budget for the RCE R₂ has a period ΔTQ₂ = 7 μsec, a relative deadline T_D2 ⁼ 7 μsec, and an execute time period ΔT_B2 ⁼ 2 μsec to execute within each period ΔT_Q2. On account of the execute time periods ΔT_BI, ΔTβ₂ completing before the ends of their respective deadlines T_DI, _D2, resource budgets for the two RCE's Ri and R₂ are therefore schedulable. In an event where the RCE Ri becomes blocked for a duration of 1 μsec at elapsed time t = 20 μsec as depicted in Fig. 4, and the RCE Ri is allowed by the resource budget scheduler (BS) to execute, a situation will arise as indicated by 100. Conceptually, a "virtual idle RCE" may be considered to consume the time that the RCE Ri is blocked. Consequently, the RCE R₂ is not able to consume its entire resource budget allocation that was replenished at elapsed time t = 21 μsec before the deadline at elapsed time t = 28 μsec causing a computing resource deficit to arise and associated incident as represented by a strike arrow symbol in Fig. 4. Hence, the RCE Ri cannot be permitted to defer the consumption of its budget at elapsed time t = 20 μsec, because this would interfere with guaranteeing computing resource budget to the RCE R₂. In a situation where the RCE R₂ becomes blocked for a duration of 1 μsec at an elapsed time t = 4 μsec, allowing the RCE R₂ to defer consumption of its budget does not yield any advantages for the RCE Ri, simply because there is no possibility for the RCE R₂ to consume any budget after elapsed time t = 5 μsec and before its period expires at an elapsed time t = 7 μsec. Thus, if a RCE is allowed to defer its resource budget, it is not guaranteed that it can actually consume the deferred resource budget. The present invention is directed at addressing such a situation. From the foregoing examples depicted in Figs. 3 and 4, a time period RCE

Ri₊i is running whilst an RCE R, is blocked must be subtracted from the guaranteed resource budget of the RCE Rj. The subtracted budget is potentially consumable as an optional budget when it remains available to the RCE R, during this period. In the aforementioned list L, the data structure DS„ and other of the data structures DS in a similar manner, is preferably extended with an additional data field including the following data groups: (a) a total optional resource budget O_BI of the RCE R, defined as being a total time the RCE Ri+i ran since the RCE Rj blocked; the optional budget O_BI corresponds to the additional time that may become available for deferred execution;

(b) a guaranteed resource budget G_BI, the guaranteed budget G_BI thereby being distinguished from the optional resource budget O_B,; RCE'S are permitted within the system 10 to inspect both budgets O_B and G_B. The guaranteed resource budget G_BI corresponds to the normal budget allocated to the RCE R,; values for the budgets G_BI, O_BI are determined by way of a method which will now be elucidated. In the method, when the RCE R, blocks, the budget 0_Bι in the corresponding data structure DS, is initialized to zero. In an event of a context switch occurring and the RCE R, stopping after having executed for a time period T_x from its resource budget, the period T_x is also subtracted from the guaranteed budget G_BJ. Thus, in the method, for the RCE Rj in the list L, the following steps are performed on its corresponding data structure DS,:

(i) the index i is defined as i=j+l, whereafter T_x is added to the optional budget

OB,; (ii) the data structures DS of other RCE's are not modified;

(iii) when a new time period starts, the guaranteed budgets G_B of the RCE's in the list L are set to the guaranteed budget for the new period;

(iv) if a given RCE is not in the list L, no additional actions are taken for that given

RCE; (v) if a given RCE is on the list L, the total optional budget O_B for that RCE is set to zero;

(vi) if a given RCE unblocks, no action regarding scheduling is needed if the given

RCE is not recorded in the list L; (vii) if a given RCE unblocks and it is recorded in the list L, its optional budget O_B is set to zero; a subtraction of the current time T minus the start time Ts minus the accumulated pre-emption time ΔTp, namely T-Ts-ΔTp, is subtracted from the remainder of the budget yielding a new temporary execute time period ΔT_B' budget and the guaranteed budget G_B is set to the maximum of: zero and the temporary time period ΔT_B'. Thereafter, the total optional budget O_B is added to the temporary time period ΔT_B' yielding a final value of resource budget for the RCE Ri in the present execution step period. It is to be noted that the optional budget O_B can be derived from the current remainder of the execution time and the guaranteed time G_B. When an RCE requests to use either the optional budget O_B or the guaranteed budget G_B, such budgets are calculated based on the amount of time the RCE has been running since a last context switch. It will be appreciated that embodiments of the invention described in the foregoing are susceptible to being modified without departing from the scope of the invention. The method of the invention described in the foregoing can be further enhanced. Referring to Fig. 4 again, it will be seen that the RCE Ri is blocked for duration of 1 μsec at first three cases corresponding to elapsed time t = 0, 15 or 25 μsec; in such a situation, the RCE R₂ could execute earlier whilst the RCE Ri is blocked. At second three cases corresponding to elapsed time t = 5, 10 or 30 μsec, the aforementioned "virtual idle RCE" would consume the blocking time. In all these six cases, deferring the consumption of the RCE Ri of its resource budget would not be a problem, namely not interfere with the budget of the RCE R₂. Whereas the first three cases are addressed by the method of the invention described earlier with regard to Fig. 3 and 4, the second three cases are not addressed by the aforementioned method. The second three cases are therefore considered in more detail: (a) at an elapsed time t = 5 μsec, the RCE Ri is susceptible to deferring the consumption of its budget by at most 1 μsec without interfering with the RCE R₂'s budget because the RCE R₂ could still consume executable time later, for example in an elapsed time t period: 13 μsec<t<14 μsec; (b) at an elapsed time t = 10 μsec, the RCE Ri is able to defer the consumption of its budget by 1 μsec without influencing the consumption of the RCE R₂'s budget, and by at most 2 sec without influencing the consumption of the budget of the RCE R₂ by R₂; The RCE R₂ is still capable of consuming its budget at a later time, for example in an elapsed time t period: 19 μsec<t<20 μsec;

(c) at an elapsed time t = 30 μsec, the RCE R₂ is able to defer the consumption of its budget by at most 2 μsec without interfering with the consumption of the budget of the RCE R₂ by R₂. Hence, for the elapsed time t = 30 μsec, the RCE Ri could defer the consumption of its budget by 1 μsec without influencing the RCE R₂'s consumption of its budget. An enhancement to the method of the invention is described below which takes advantage of allowing the RCE R₂ to consume at a later time execution resource "slack" that it has itself generated. The enhancement of the foregoing method is preferably implemented by instituting a separate dedicated middle-priority band for generated slack. For example, when the RCE Rj blocks and the RCE Rj is running wherein indices j>i+l, the slack generated by the RCE Rj becomes available as additional resource budget in the middle-priority band. Unlike a normal resource budget, this middle-priority band budget is not guaranteed. In summary, the methods described in the foregoing for coping with computing resource allocation between concurrently executing RCE's where a first RCE executing on computing hardware blocks awaiting data from a hardware device, the methods provide three solutions:

(a) an indication of available resource budget is determined by subtracting a blocking period minus a pre-emption time from a remainder of the budget; (b) the time period an RCE with a lower priority is executing whilst an RCE with a higher priority is blocked is subtracted from the guaranteed budget from the higher priority RCE to yield an optional budget that may be consumed as optional budget by the higher RCE when this optional budget remains available to this higher RCE; in an event the optional budget is not consumed, it becomes lost; (c) a middle-band priority is provided for generated resource slack so that when a

RCE with a higher priority blocks and a RCE with a lower priority is executing, the slack generated by the higher priority RCE becomes available as additional budget in the middle priority band. The method allows more effective scheduling of concurrent RCE's and thereby assists to maximize budget when blocking occurs. In the foregoing, and also with regard to the appended claims, expressions such as "include", "comprise", "contain", "incorporate", "have" and "is" are to be construed non-exclusively, namely allowing for one or more items or components not explicitly disclosed also to be present. Reference to the singular is also to be construed as referring to the plural and vice versa.

Claims

CLAIMS:

1. A method of handling deferred execution, characterized in that the method includes the steps of:

(a) providing a computer system (10) for concurrently executing resource consuming entities, each entity comprising one or more software processes and/or one or more hardware devices;

(b) arranging for the system (10) to include resource scheduling means for allocating computing resources between the resource consuming entities;

(c) arranging for the scheduling means to include a list of data structures corresponding to those of the resource consuming entities subject to blocking; (d) arranging for the scheduling means to determine for a first resource consuming entity blocked by one or more second resource consuming entities a blocking time instance at which the first entity is blocked, and a pre-emption time corresponding to execution time of the one or more second resource consuming entities;

(e) determining from a measure of present time, the blocking time and the pre- emption time remaining an available executing time for the first entity; and

(f) arranging for the scheduling means to direct the first entity to execute during the remaining executing time.

2. A method according to Claim 1, wherein the computer system is arranged to execute the resource consuming entities periodically, and the scheduling means is operable to replenish resource allocations including in the list at commencement of each period.

3. A method according to Claim 1, wherein data structures corresponding to those of the resource consuming entities that are blocked are dynamically updated as the data structures become blocked or unblocked.

4. A method according to Claim 1, wherein computing resources becoming available in consequence of the first resource consuming entity blocking become available for executing one of more second resource consuming entities which are out-of-budget with regard to their resource allocations.

5. A method according to Claim 1, wherein the scheduling means is operable to determine from the list one or more guaranteed resource budgets and one or more optional resource budgets, the one or more optional resource budgets being available for high priority resource consuming entities recorded in the list and being susceptible to being lost if not consumed within one or more given time periods.

6. A method according to Claim 1, further comprising a step of:

(g) arranging for the scheduling means to provide a middle-band priority in which resource slack generated from higher priority resource consuming entities is made available to relatively lower priority resource consuming entities.

7. A method according to Claim 6, wherein the resource slack is subsequently made available to higher priority resource consuming entities responsible for generating the resource slack.

8. A computer system for executing resource consuming entities, each entity comprising one or more software processes, the system operable to schedule execution of the resource consuming entities according to the method of Claim 1.

9. Computer resource scheduling software executable on a computer system, said software operable to implement the method according to Claim 1.

10. A computer readable medium having stored thereon instructions for causing one of more processing units to perform the method according to any of the claims 1 to 7.