We consider the preemptive scheduling of real-time tasks on identical multiprocessor platforms (see [baker2, Baker2005An-analysis-of-]). We deal with parallel real-time tasks, the case where each job may be executed on different processors simultaneously, i.e., we allow job parallelism. Nowadays, the design of parallel programs is common thanks to parallel programming paradigms like Message Passing Interface (MPI [Gorlatch1998A-Generic-MPI-I, Lusk1999Using-MPI-:-por]) or Parallel Virtual Machine (PVM [Sunderam1990PVM:-A-Framewor, Geist1994PVM:-Parallel-V]). Even better, sequential programs can be parallelized using tools like OpenMP (see  for details).
Few models and results in the literature concern hard real-time and parallel tasks. Manimaran et al. in [mani98] consider the non-preemptive EDF scheduling of periodic tasks. Han et al. in [han89] considered the scheduling of a (finite) set of real-time jobs allowing job parallelism while we consider the scheduling of either infinite set of jobs or equivalently a set a periodic tasks. In previous work we contributed mainly to the feasibility problem of parallel tasks. In [CCG06b] we provided a task model which integrates job parallelism. We proved that the time-complexity of the feasibility problem of these systems is linear relatively to the number of (sporadic) tasks. More recently, we considered the scheduling of jobs which are composed of phases to be executed sequentially ; in [Berten2009Feasibility-Tes] we provided a necessary feasibility test. Regarding the schedulability of recurrent real-time tasks, and to the best of our knowledge, we can only report the S. Kato et al. work (see [kato2009gang] for details) which considers the Gang scheduling of rigid tasks (the number of processors is fixed beforehand) and provides a sufficient schedulability condition for Gang EDF scheduling.
In this paper we study the scheduling of recurrent and parallel rigid tasks. Our main contribution is an exact schedulability test for Fixed Task Priority (FTP) Gang schedulers. Additionally, we study the predictability of our schedulers: we show that Gang FJP schedulers are not predictable and we identify several sub-classes which are actually predictable. Our technique is based on previous work for the scheduling of periodic tasks upon multiprocessors [dateLCJG07, etfaLCJG06]. To summarize the technique, we characterized for FTP schedulers and for asynchronous periodic task models, upper bounds of the first time-instant where the schedule repeats. Based on the upper bounds and the predictability property, we provide exact schedulability tests for asynchronous constrained deadline periodic task sets. The predictability property is important in the technique and will be revisited in this work. We also extend the definition of rigid, moldable and malleable jobs to recurrent tasks.
This paper is organized as follows. Section 2 introduces definitions, the model of computation and our assumptions. In Section 3 we study the predictability of our system, in particular we show that Gang FJP schedulers are not predictable and we identify several sub-classes which are actually predictable. We prove the periodicity of feasible schedules of periodic systems in Section 4. In Section 5 we combine the periodicity and predictability properties, to provide, for our Gang FTP sub-classes, an exact schedulability test. Lastly, we conclude in Section 6.
2 Model and Definitions
2.1 Parallel Terminology
The parallel literature [Drozdowski2005Scheduling-Para, Buyya99, Feitelson96towardconvergence] defines several kind of parallel tasks. But tasks in the non real-time parallel terminology does not have the same meaning as tasks in real-time scheduling literature. Actually, tasks in the parallel literature corresponds to jobs in our real-time community (i.e., corresponds to task instance). Especially, the notion of rigid recurrent task is not defined and does not extend trivially from the non real-time literature, in this section we fill the gap.
Definition 1 (Rigid, Moldable and Malleable Job).
A job is said to be:
if the number of processors assigned to this job is specified externally to the scheduler a priori, and does not change throughout its execution;
if the number of processors assigned to this job is determined by the scheduler, and does not change throughout its execution;
if the number of processors assigned to this job can be changed by the scheduler during the job’s execution.
Definition 2 (Rigid, Moldable and Malleable Recurrent Task).
A periodic/sporadic task is said to be:
if all its jobs are rigid, and the number of processors assigned to the jobs is specified externally to the scheduler;
if all its jobs are moldable;
if all its jobs are malleable.
Notice that a rigid task does not necessarily have jobs with the same size. For instance, if the user/application decides that odd instances requireprocessors, and even instances processors, the task is said to be rigid.
2.2 Task and Job Model
We consider the preemptive scheduling of parallel jobs on a multiprocessor platform with processors. We will focus on the problem of scheduling a set of parallel jobs, each job is characterized by a release time , a required number of processors, an execution requirement and an absolute deadline . The job must execute for time units over the interval on processors. We consider the scheduling of rigid tasks since is fixed externally to the scheduler. Actually, S. Kato et al. in [kato2009gang] have the same assumption as we do, and, given the Definition 2, they consider rigid tasks, and not moldable tasks, as said in their paper — otherwise the scheduler would determine on-line and at job-level.
As we will consider periodic systems, let denote a set of periodic parallel tasks. Each task will generate an infinite number of jobs, where the job of task is
The execution requirement of a job of corresponds as a rectangle. In this document we assume for any , i.e., we consider constrained deadline systems. We consider multiprocessor platforms composed of identical processors: .
2.3 Priority Assignment and Schedulers
In this document we consider FTP and FJP schedulers with the following definitions.
Definition 3 (Ftp).
A priority assignment is a Fixed Task Priority assignment if it assigns the priorities to the tasks beforehand; at run-time each job priority corresponds to its task priority. (An FTP scheduler uses an FTP priority assignment.)
We assume that tasks are indexed according to priority (lower the index, higher the priority).
Definition 4 (Fjp).
A priority assignment is a Fixed Job Priority assignment if and only if it satisfies the condition that: for every pair of jobs and , if has higher priority than at some time-instant, then always has higher priority than . (An FJP scheduler uses an FJP priority assignment.)
Remark that any FTP assignment is also FJP.
Definition 5 (Gang FJP).
At each instant, the algorithm schedules jobs on processors as follows: the highest priority (active) job is scheduled on the first available processors (if any). The very same rule is then applied to the remaining active jobs on the remaining available processors.
Figure 1 illustrates the Gang FTP schedule ( is the highest priority task and the lowest one) of . Notice that Gang FJP and FTP can produce schedules where a lower-priority job () is scheduled while an active higher-priority job () is not (typically if — which occurs at time in our example, and are active, is executing in while is not). This phenomenon, called priority inversion in this document, could be a drawback as we will see. Fortunately, we keep an important FTP-property: the scheduling of the sub-set is not jeopardized by lower-priority tasks ().
Definition 6 (Schedule ).
For any set of jobs and any set of identical processors we define the schedule of system at time-instant as
Definition 7 (Availability of the processors).
For any ordered set of jobs and any set of processors , we define the availability of the processors of the set of jobs at time-instant as the set of available processors: , where is the schedule of .
Definition 8 (Active, Ready and Running jobs).
A job is said to be active if it has been released, but is not finished yet. An active job is ready if it is not currently served ; an active job is running otherwise.
3 Predictability of Gang Scheduling
We consider the scheduling of sets of job , (finite or infinite set of jobs) and without loss of generality we consider jobs in a decreasing order of priorities ). We suppose that the execution time of each job can be any value in the interval and we denote by the job defined as . We denote by the set of the first higher priority jobs. We denote also by the set and by the set . Let be the time-instant at which the lowest priority job of begins its execution in the schedule. Similarly, let be the time-instant at which the lowest priority job of completes its execution in the schedule.
Definition 9 (Predictable algorithms).
A scheduling algorithm is said to be predictable if and , for all and for all schedulable sets of jobs.
Notice that the predictability of an algorithm implies that any system schedulable when all tasks use their worst case execution time is also schedulable when a task takes less time than expected. We then just need to show that the system is schedulable in the worst case to prove that the system is schedulable in all scenarios.
In previous work [Cucu-Grosjean2009Predictability-] we proved, for a quite general model, i.e., FJP priority schedulers on unrelated multiprocessors, the predictability for sequential jobs (i.e., for any ). Unfortunately that property is not satisfied for parallel jobs.
Gang FJP schedulers are not predictable on multiprocessors.
Here is an example task system, on 2 processors (see Figure 2):
Upon two processors and using the priority assignment , Gang FJP schedules the set of jobs ( completes at time-instant 2). Unfortunately, if the actual duration of is 1, will preempt at time and will complete later, at time-instant 3. Then, does not miss its deadline in the “worst case” scenario, but misses it if uses less than its worst case execution time . ∎
This negative result implies that neither the DM, RM nor EDF are predictable for Gang scheduling.
The problem we highlight in this example occurs because some jobs which were not preempted in the worst case scenario are preempted in a scenario with shorter execution times. In other words, by allowing a job taking advantage of some slack time given by another (higher priority) job, interrupts a job (with ) which would not have been suspended if we did not have any slack.
If, as we will do and prove in this work, we find a way to avoid the priority inversion phenomenon, we will never have those problematic preemptions. Indeed, if no lower priority job is authorized to start between the arrival of () and its start time, then if starts anywhere between its arrival time, and its start time in the worst case scenario, it will not interrupt tasks that it would not have interrupt in the worst case.
The “problematic preemptions” can be avoided by (at least) three ways:
By avoiding the priority inversion;
By avoiding any slack (or by not using it);
By using the slack, but in a “smart” way.
In order to obtain a predictable system, we identify two ways of modifying the system:
First, we will propose to constraint the priority assignment. We introduce the Parallelism Monotonic FTP assignment, and prove the predictability of these priority assignments;
Second, we will propose three variants of the scheduler, giving a predictable behavior. Those variants are the idling scheduler (not using the slack), the limited Gang FJP scheduler (avoiding priority inversion), and the Gang FJP scheduler with limited slack reclaiming (smartly using the slack).
3.1 Parallelism Monotonic FTP Assignment
In this section we will consider a sub-class of Gang FTP assignments which are predictable.
Definition 11 (Parallelism Monotonic).
An FTP priority assignment is Parallelism Monotonic iff .
Notice that this class is very interesting from the theoretical point of view, but might be not a good choice for some implementation. Indeed, it gives a low priority to highly parallel jobs, which makes them more difficult to schedule. In general, it might be useful to first schedule the very parallel jobs, and then to fill the available processors with smaller jobs.
We will now prove that any Parallelism Monotonic assignment are predictable.
In [Cucu-Grosjean2009Predictability-] we showed that , for all and all . In other words, that at any time-instant the processors available in are also available in . The counterexample used in the proof of Lemma 10 violates that property as well. In the following we will consider another kind of processors availability.
Definition 12 (Level-() availability of the processors).
For any ordered set of jobs and any set of processors, we define the level-() availability of the processors of the set of jobs at time-instant as follows
Informally speaking, is the the number of available processors if the latter is sufficient to schedule , otherwise is null.
For any schedulable ordered set of jobs , using a Gang FJP Parallelism Monotonic on processors, we have , for all and all . (We consider that the sets of jobs are ordered in the same decreasing order of the priorities, i.e., and .)
The proof is made by induction on (the number of jobs). Our inductive hypothesis is the following: , for all and .
The property is true in the base case since , for all . Indeed, . Moreover and are both scheduled on the (same) first processors, but will be executed for the same or a greater amount of time than .
We will show now that , for all .
Since the jobs in have higher priority than , then the scheduling of will not interfere with higher priority jobs which have already been scheduled. Similarly, will not interfere with higher priority jobs of which have already been scheduled. Therefore, we may build the schedule from , such that the jobs , are scheduled at the very same instants and on the very same processors as they were in . Similarly, we may build from .
Note that property is straightforward for time-instants where is not scheduled since the processor availability is not modified and by definition of level-() processor availability.
We will consider time-instant , from to the completion of (which is actually not after the completion of , see below for a proof), we distinguish between three cases:
: in both situations no enough processors are available for (and ). Therefore, both jobs, and , do not progress and we obtain , since . The progression of is identical to .
: progress on the first available processors in (not available in ). does not progress. since . The progression of is strictly larger than .
, and progress on the same processors. The property follows by induction hypothesis.
Therefore, we showed that , for all , from to the completion of and that does not complete after . For the time-instant after the completion of the property is trivially true by induction hypothesis. ∎
Gang FJP schedulers are predictable on identical platforms with Parallelism Monotonic priority assignment.
In the framework of the proof of Lemma 13 we actually showed extra properties which imply that Gang FJP Parallelism Monotonic schedulers are predictable on identical platforms: (i) completes not after and (ii) can be scheduled either at the very same instants as or may progress during additional time-instants (case (2) of the proof) these instants may precede the time-instant where commences its execution. ∎
3.2 Idling Scheduler
Instead of giving constraints on the priority assignment, we can also adapt our scheduler in order to make it predictable. A first way of doing that is to force tasks to run exactly up to their worst case. If a task does not use its worst case, then the scheduler idles the processor(s) up to the expected end time.
Definition 15 (Idling scheduler).
An idling scheduler idles any processor that was used by a task which finished earlier than its worst case, up to the time the processor would have been released in the worst case scenario.
Gang FJP Idling schedulers are predictable on identical platforms.
The proof is very straightforward in this case: any task starts at the same time in the worst case , and in the case where some tasks use less than than their worst case. And if we consider the completion time of a job as the time at which its (possibly empty) idle period finishes, then the end time will be the same in the worst case scenario as in any case. Then,
3.3 Limited Gang FJP Scheduler
The predictability can also be ensured if we avoid the priority inversion phenomenon reported in Section 1, more precisely by restricting Gang FTP/FJP as follows:
Definition 17 (Limited Gang FJP scheduler).
At each instant, the algorithm schedules jobs on processors as follows: the highest priority (active) job is scheduled on the first available processors (if any). The very same rule is then applied to the remaining active jobs on the remaining available processors only if was scheduled (i.e., if at least processors were available).
We now prove that limited Gang FJP are predictable but first an additional definition.
Definition 18 (Limited level-() availability of the processors).
For any ordered set of jobs and any set of processors, we define the limited level-() availability of the processors of the set of jobs at time-instant as follows ( for all ):
For any schedulable ordered set of jobs , using a Limited Gang FJP on processors, we have , for all and all . (We consider that the sets of jobs are ordered in the same decreasing order of the priorities, i.e., and .)
The property follows using a similar reasoning as the proof of Lemma 13 and the fact that ∎
Limited Gang FJP schedulers are predictable on identical platforms.
The proof is similar to the proof given for Theorem 14. describes the number of processors available to schedule . As this number is at any time higher in than in , then will never start later in than in , and will never finish later either. ∎
Remark that by using limited Gang scheduling we accept to lose efficiency in the resource utilization to ensure system predictability.
3.4 Gang FJP and Limited Slack Reclaiming
As highlighted previously, the problem of using the slack caused by a job finishing earlier than expected is that it could cause a preemption that would not have occurred if the job had used its worst case execution time. But with a closer look, we can see that the problem only occurs when a job wider than a job () takes advantage of the slack created by early completion. A way of avoiding this is to only allow job not larger than the early completed job to use the slack. This is what we propose in this technique.
Definition 21 (Slack server).
A slack server of level , width and length is a job of priority , on processors, running for units of time, serving jobs with a priority lower than which do not require more than processors. If no task are available, the server stays idle until the end of the units of time.
It may be noticed that:
We do not give any constraint about the way the “slack server scheduling” (the way jobs are scheduled inside the slack server) is performed;
Within a slack server, we might run several jobs in parallel, as long as they never need more than processors simultaneously;
If a job being served by the slack server becomes eligible by the “global scheduler”, then it should be interrupted in the slack server, and made available to the global scheduler;
All jobs served by the slack server should still stay in the ready state (but not running) from the “global scheduler” point of view.
Regarding this definition of a slack server, we can now define how our schedule will work.
Definition 22 (Gang FJP and limited slack reclaiming).
A Gang FJP scheduler with limited slack reclaiming, works as follows: At each scheduling point (the completion of a job or an arrival):
If this corresponds to the end of a job , and this job used units of time, starts a slack server of level , width , length ;
Otherwise, the highest priority (active) job is scheduled on the first available processors (if any). The very same rule is then applied to the remaining active jobs on the remaining available processors.
We can make an important observation about this scheduling algorithm. Jobs that are run in the slack server will not have any other impact on the global scheduler that reducing the execution time of those jobs. So if we consider the slack server as a black box, the schedule will be exactly the same as if this black box was just idling. The only impact will be the proportion between actual and worst case execution time.
Remark also that will we cause priority inversion: some jobs will be run inside the slack server, while other higher priority ready job (but wider than the slack server) will be kept suspended.
Figure 3 illustrates how the slack server works. We consider the following set of jobs (they all have the same arrival time , and the same deadline :
The left side of Figure 3 shows the schedule where all jobs use their worst case execution time. On the right side, finishes at time (instead of ). The schedulers launches then a slack server (in gray on the figure) of level , width and length , in order to fill the space that would have been used by in the worst case scenario. This server is then scheduled as a job of priority , as was . At time , the slack server sees that jobs , , , are ready ( is running). But is too wide, so the slack server can for instance choose (arbitrarily) to run and . After one unit of time, the scheduler sees that it can run , the highest priority task which can run on the only available processor released by the end of . is then “preempted” inside the slack server, and run normally. Then the slack server choses to run ( is done). At time , the slack server ends, and is preempted.
At time and , we need to start slack servers for , and , but they do not receive any work to perform.
Remark that if we compare both schedules of Figure 3, and see the slack server as part of the concerned job, all tasks start end and at the same time in both scenarios.
Gang FJP schedulers with limited slack reclaiming are predictable on identical platforms.
From the schedulability point of view, this behaves exactly the same way as the Idling server. But instead of being idle, the slack server decreases the actual execution time of some ready (but not running) jobs.
One job will never preempt a job that would not have been preempted in the worst case scenario. ∎
Notice that with this kind of scheduler, we might considered the system as being not fully FTP anymore. Some jobs are indeed eligible (enough resource to run them), but are left waiting. In the presentation of this section, we said that we did not give any constraint on the scheduler of the slack server. Indeed, the method we use does not have any impact on the predictability of the system. But we can of course use a FTP scheduling algorithm. This does not make the global system to be strictly FTP, but it makes closer.
Notice also that we present a system with two level of scheduler: one global, and one inside the slack server. This distinction was used for the sake of presentation, but in a real implementation, the global scheduler can of course also do the job of the slack server scheduler.
In this section we prove the periodicity of feasible Gang FTP schedules. It is important to note that we assume in this section that each job of the same task (say ) has an execution requirement which is exactly time units. Thanks to the predictability property this situation corresponds to the worst case.
Remark that, as we consider only the case where all job has its worst case, the schedule of an idling, slack reclaiming or general scheduler is exactly the same.
For any preemptive (limited or not) Gang FTP algorithm , if an asynchronous constrained deadline system is -feasible, then the -feasible schedule of on identical processors is periodic with a period from instant where is defined inductively as follows:
(Assuming that the execution time of each task is constant.)
The proof is made by induction on (the number of tasks). We denote by the schedule obtained by considering only the task subset , the first higher priority tasks , and by the corresponding availability of the processors. Our inductive hypothesis is the following: the schedule is periodic from with a period for all .
The property is true in the base case: is periodic from with period , for : since we consider (feasible) constrained deadline systems, at instant the previous request of has finished its execution and the schedule repeats.
We shall now show that any -feasible schedule of is periodic with period from .
Since is periodic with a period from the following equation is verified:
We denote by the first request of not before .
Since the tasks in have higher priority than , then the scheduling of will not interfere with higher priority tasks which are already scheduled. Therefore, we may build from such that the tasks are scheduled at the very same instants and on the very same processors as they were in . We apply now the induction step: for all in we have the availability of the processors repeats. Notice that at those instants and the available processors (if any) are the same. Consequently at only these instants where , task may be executed. Notice that the scheduler can decide to leave one or several processor(s) to be idle intentionally in a deterministic and memoryless way. Notice also, in the “non limited case”, that might start executing before a higher priority task (with ), if . But as soon as processors are available in , is preempted (if still running) and the CPU is given to .
The instants with , where may be executed in , are periodic with period since is a multiple of . Moreover since the system is feasible and we consider constrained deadlines, the only active request of at , respectively at , is the one activated at , respectively at . Consequently, the instants at which the deterministic and memoryless algorithm schedules are periodic with period . Therefore, the schedule repeats from with period equal to and the property is true for all , in particular for is periodic with period equal to from and the property follows. ∎
5 Exact Schedulability Test
Now we have the material to define an exact schedulability test for rigid and asynchronous periodic systems.
For any preemptive Gang FTP predictable algorithm (i.e., Parallelism Monotonic, Idling, Limited Gang, and Limited Slack Reclaiming variants) and for any asynchronous rigid constrained deadline system on identical processors, is -schedulable if and only if
all deadlines are met in and
where are defined inductively in Theorem 24.
6 Conclusion and Future Work
In this paper we considered the scheduling of periodic and parallel rigid tasks. We provided and proved correct an exact schedulability test for Fixed Task Priority (FTP) Gang scheduler sub-classes: Parallelism Monotonic, Idling, Limited Gang, and Limited Slack Reclaiming. Additionally, we studied the predictability of our schedulers: we show that Gang FJP schedulers are not predictable and we identify several sub-classes which are actually predictable. We also extended the definition of rigid, moldable and malleable jobs to recurrent tasks.
In future work we aim to extend the model by considering moldable tasks — task can be executed in a varying number of processors — that is the scheduler can determine, on-line, the rectangle of each task instance (job) based upon parallel performance model (e.g., the one defined in [CCG06b]).