1 Introduction
In this paper we consider the schedulability of the NonCyclic Generalized Multiframe Task Model System Model defined by Moyo et al. [7] (ncgmf in short). Moyo et al. provided a sufficient EDF schedulability test, Baruah extended the model by considering the Noncyclic recurring task model [1] and provided an exact feasibility test. Stigge et al. further extend this model and consider Digraph realtime task model [8], and consider the feasibility (or, equivalently, the EDFschedulability) of their task model.
Formally, an ncgmf task set is composed of tasks . An ncgmf task is characterized by the 3tuple where , , and are
ary vectors
of execution requirement, of (relative) deadlines, and of minimum separations, respectively. Additionally each task makes an initial release not before timeinstant .The interpretation is as follows: each task can be in different configurations, where configuration with corresponds to the triplet . We denote by the configuration of the frame of task . The first frame of task has an arrival time , an execution requirement of , an absolute deadline and a minimum separation duration of with the next frame. The frame has an arrival time , an execution requirement of , an absolute deadline and a minimum separation duration of with the next frame.
It is important to notice that can be any value in for and . I.e., the exact order in which the different kinds of jobs are generated is not know at designtime, it is noncyclic. In this way this model generalizes the gmf model [2].
In this research we consider the scheduling of ncgmf using Fixed Task Priority (ftp) schedulers and without loss generality implies that has a higher priority than . Notice that, while having a model and solutions close to ours, [8] considers dynamic priority tasks. Even if a very similar mechanism (the request bound function) works very well with dynamic priorities allowing one to provide necessary and sufficient feasibility tests, it introduces some pessimism with fixed priorities, leading to a sufficient schedulability test.
This research. Our goal is to provide a sufficient schedulability test —ideally polynomial— for the scheduling of ncgmf using ftp schedulers. We report two first results: (i) we present and prove correct the critical instant for the ncgmf then (ii) we propose an algorithm which provides a sufficient (but pseudopolynomial) schedulability test.
2 Critical Instant
First notice that the popular critical instant notion (see Definition 1) is not really applicable in our task model.
Definition 1.
A critical instant of a task is a time instant such that: the job of at this instant has the maximum response time of all job of .
This notion is difficult to extend to noncyclic model in the sense that the workload (task requests) is not unique, contrary to the Liu and Layland or the (cyclic) gmf task model.
Anyway, the critical instant is important because it provides the worstcase scenario from standpoint, in the next section we will show that the synchronous case remains the worst case for the more general model namely the ncgmf.
Definition 2.
Let us consider an ncgmf task set , where is described by
The scenario of task , denoted by , is a value (the initial release time) associated with an infinite sequence of tuples , with:

,

.
If task follows the scenario , then:

the first job is released at time , has an execution requirement of and a relative deadline ,

the job () is released at time , has an execution requirement of and a relative deadline .
In this work we consider offset independent scenarios with the following definition:
Definition 3.
A scenario is said to be offset independent if it depends neither on , nor on the schedule. In other words, if we shift by the first arrival, all arrivals will be shifted the same way, and the jobs will keep the same characteristics.
A scenario obtained in shifting by is described by:
Definition 4 (From [4]).
An idle instant occurs at time in a schedule if all jobs arriving strictly before have completed their execution before or at time in the schedule.
Theorem 5.
For any task the maximum response time occurs when all higher priority tasks release a new task request synchronously with and the subsequent requests arrive as soon as possible.
Proof.
We^{1}^{1}1This proof is based upon lecture slides, the authors thank S. Funk and J. Anderson. It corrects [5, 6] for the popular sporadic task model. consider a job in a given scenario and we will show that, by shifting the job releases of higher priority tasks, in the synchronous case the response time of the job does not decrease. Since that property holds whatever the scenario we can conclude that the worst case response time occurs in a synchronous scenario, hence the property.
Let be the release time. Let be the latest idle instant for the scheduling of at or before . Let denote the time instant when completes. (See Figure 1.)
First, if we (artificially) redefine release time to be then remains unchanged but the response time may increase.
Assume now that releases a job at and some higher priority task does not. If we leftshift such that its first job is released at time then response time remains unchanged or is increased (since we consider offset independent scenarios). We have constructed a portion of the schedule that is identical to the one which occurs at time when release job together. This shows that asynchronous releases cannot cause larger response time than synchronous release (for the same scenario).
It remains to show that the leftshift does not impact on . It may be noticed that no job shift pasts , every job that starts after continues to do so after the shift by construction. Similarly, any job that starts before continues to do so after the shift and remain an idle instant: for each interval , no job shift into this interval, no left shifts cross , therefore the total demand during cannot increase, therefore the last completion time prior to cannot be delayed.
The same argument (i.e., the leftshift) can be used to complete the proof and show that the worst case response time occurs when the subsequent requests arrive as soon as possible. ∎
3 Schedulability Test
3.1 Request Bound Function
In order to provide a schedulability test, we will use a similar approach to the one used by [9, 3, 8], in order to bound the computation demand that a task can request. From the previous section, we know that a scenario has its worst demand when the first request arrives at time , and all other requests arrive as soon as possible. I.e., and . This kind of scenario will be called a dense scenario.
In the following, we define a sporadic scenario as a scenario were exact release times are let free. A sporadic scenario is then determined by a sequence of configuration numbers with . Theorem 5 says then amongst all the possible arrival pattern of a sporadic scenario, the dense scenario is the worst.
From this, we provide a new definition:
Definition 6.
Given a sporadic scenario of a task , we define the Request Bound Function as the maximal total demand that can request in the interval . Formally,
In the single frame model, where there is only one possible (sporadic) scenario, this corresponds to the Request Bound Function [3]. In the framework of feasibility for dynamic priorities, authors of [8] consider Demand Bound Function, instead of Request Bound Function.
Some example of such request bound functions are shown in Figure 2(a)–2(c). We can observe that a request bound function is always composed of a sequence of connected steps, where the step is composed of a vertical jump of , followed by a horizontal segment of length .
Let us now assume that the (sporadic) scenario is fixed for all tasks , is proved to be schedulable, and we want to know if the system is still schedulable if we add a task . Adapting the results from [9], we need to check that, if starting synchronously with all higher priority tasks, can still meet its deadline. As can have different configurations, we need to find the smallest solution to the following inequalities:
(1) 
If we now want to check the schedulability of any task system, we need to raise the hypothesis that the scenarios are known, and consider all the possible combinations of scenarios. But checking the schedulability through this method would be impossible within a reasonable amount of time, even for small problem instances.
In the following, we propose to bound all the possible request bound functions for a given task, and to use this bound instead of all possible scenarios. This will make the problem tractable, but at the price of loosing the exactness of the schedulability test (as explained in Section 3.3).
3.2 Maximum Request Bound Function
In the following, we will focus on the maximal request that a task can produce in the interval , whatever the scenario.
Definition 7.
The Maximum Request Bound Function of a task represents an upper bound on the demand that task can request up to any time . Formally,
where represents all the possible dense scenarios of .
Notice the mrbf is not the maximum of all the rbf’s (such a maximum does not exist in general), but a function which, for each , gives the maximum of all .
Examples of such mrbf functions can be seen in Figures 2(d)–2(e). Before explaining how this mrbf can be practically computed, here is how we use it:
Theorem 8.
An ncgmf task set is schedulable using an ftp assignment if, , the smallest positive solution to the equality
is not larger than .
3.3 Pessimism
As we stated before, this technique introduces some pessimism. Here is a simple example explaining why. Let us consider a system with two tasks, where is described in Figure 2(a)–2(d), and contains only one configuration with and . A way of proving that this system is schedulable is to consider the rbf of all possible scenarios for , and to see if can process its single unit of work within the three first units of time. For every scenario , it boils down to find a such that . This is obviously the case for Figure 2(a) (), (b) () and (c) (). We let the reader check the other cases. However, we could not find such a with mrbf, which implies that our test could not conclude the schedulability of the system.
As a future work, we would like to quantify this pessimism, i.e., study how much exactness we loose by considering mrbf instead of all the rbf’s separately. We hope to be able to bound this pessimism by a constant : if our test attests the nonschedulability of a task system on a unit speed CPU, then it is for sure not schedulable on a CPU of speed .
3.4 Algorithm
Computing can be done in a very similar way as in the context of dynamic priorities [8]. We present the algorithm (Algorithm 1) here for the sake of completeness.
The basic idea is to store in a queue () points where a (dense) scenario can pass (i.e., one step stops at this point. In Figure2, this corresponds to the rightmost point of a vertical segment). We first add the point (line 1), and then all the points that can be reached from , i.e., (lines 1 through 1). Of course, we only add a point if it is not already in the queue, as observed in [8] (line 1).
Notice that we only need to get mrbf until the maximal deadline of tasks with a lower index, represented by (line 1).
3.5 Bounding mrbf
In order to efficiently compute mrbf, as well as to give some approximation, it is useful to bound this function. Before giving some bound, we will first define some value. The maximal slope is defined as . Notice that could correspond to several configurations of . The maximal amount of work is given by .
We also need to define , the computation requirement corresponding to the maximal slope (or the maximum of them if several configurations correspond to the maximal slope): .
Property 9.
.
Proof.
In order to prove that is always below the line , we will show that no scenario can ever have any point above this line. First, we remind that a scenario is a set of connected steps, each of them composed of one vertical jump of some value , followed by a horizontal segment of the corresponding . One step represents the contribution of one job of in its configuration .
The proof is done by contradiction. Let us assume that a scenario contains a point above the line, i.e., such that . Without loss of generality, we can assume that this point is the leftmost point of the segment it belongs to. By construction, this point is in the middle of the contribution of some configuration of , and this contribution starts at . Note that as , this point is above the line . We should now find a sequence such that and . This is impossible, as it would mean that, in average, the contributions of the jobs would have a slope larger than , which is a contradiction. ∎
Property 10.
.
Proof.
In order to prove this property, we simply build a scenario which respects the condition . As by definition, for any scenario of , this will make the proof. The scenario consists in choosing infinitely many times the configuration with the highest slope, i.e., the one corresponding to . Trivially, this scenario “touches” on the right side of each horizontal segment. ∎
With a similar argument, we could refine our lower bound:
(2) 
We let the formal proof for a longer version of this paper.
Property 11.
No scenario going through such that can ever coincide with after .
Proof.
4 Open Questions and Conclusion
In this work, we provide a sufficient schedulability test for the scheduling of ncgmf tasks using ftp schedulers.
There is still a lot of work to be done in that direction. Here are a few examples of our plans for the very near future.

We observed that starting from a value we still need to quantify, follows a periodic pattern of size . We hope to find a fast way to compute this pattern and when it starts. This might allow strongly improving the complexity of computing .

As already stated, our method introduces some pessimism that we would like to quantify, and hopefully bound.

We would like to adapt the technique presented in [3] in order to define a polynomial approximation scheme for our schedulability test, combining for steps with for higher values. However, the complexity of computing steps of mrbf is much more complex than in [3] where computing steps is in . We will need to bound the complexity of getting steps of mrbf; the previous item will be a first step before we get this result.

We also plan to adapt our technique to the more general model of Digraph tasks [8]. We believe that it should not be very difficult, but we will need to adapt the proof of the critical instant and the algorithms.
Acknowledgment
We would like to warmly thank Sanjoy Baruah, from the University of North Carolina (Chapel Hill), for posing the problem and for the very interesting and useful discussions we had together.
References
 [1] Baruah, S. The noncyclic recurring realtime task model. In Proceedings of the 2010 31st IEEE RealTime Systems Symposium (2010), IEEE Computer Society, pp. 173–182.
 [2] Baruah, S., Chen, D., Gorinsky, S., and Mok, A. Generalized multiframe tasks. RealTime Systems 17, 1 (1999), 5–22.
 [3] Fisher, N., and Baruah, S. A polynomialtime approximation scheme for feasibility analysis in staticpriority systems with arbitrary relative deadlines. In Proceedings of the EuroMicro Conference on RealTime Systems (2005), IEEE Computer Society Press, pp. 117–126.
 [4] Goossens, J., and Baruah, S. Multiprocessor algorithms for uniprocessor feasibility analysis. In Proceedings of the seventh International Conference on RealTime Computing Systems and Applications (Cheju Island (South Korea), December 2000), IEEE Computer Society Press.
 [5] Liu, C. L., and Layland, J. W. Scheduling algorithms for multiprogramming in a hardrealtime environment. Journal of the Association for Computing Machinery 20, 1 (January 1973), 46–61.
 [6] Liu, J. W. S. RealTime Systems. Prentice Hall, 2000.
 [7] Moyo, N., Nicollet, E., Lafaye, F., and Moy, C. On schedulability analysis of noncyclic generalized multiframe tasks. In 22nd Euromicro Conference on RealTime Systems (2010), IEEE, pp. 271–278.
 [8] Stigge, M., Ekberg, P., Guan, N., and Yi, W. The digraph realtime task model. In IEEE RealTime and Embedded Technology and Applications Symposium (2011), pp. 71–80.
 [9] Tindell, K., Burns, A., and Wellings, A. An extensible approach for analysing fixed priority hard realtime tasks. Journal of RealTime Systems 6, 2 (1994), 133–151.
Comments
There are no comments yet.