Sufficient FTP Schedulability Test for the Non-Cyclic Generalized Multiframe Task Model

10/26/2011
by   Vandy Berten, et al.
0

Our goal is to provide a sufficient schedulability test -ideally polynomial- for the scheduling of Non-Cyclic Generalized Multiframe Task Model using Fixed-Task-Priority schedulers. We report two first results: (i) we present and prove correct the critical instant for the Non-Cyclic Generalized Multiframe Task Model then (ii) we propose an algorithm which provides a sufficient (but pseudo-polynomial) schedulability test.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

07/13/2019

Skew Generalized Cyclic Code over R[x_1;σ_1,δ_1][x_2;σ_2,δ_2]

This article studies two dimensional skew generalized cyclic (SGC) codes...
06/20/2018

Weight distribution of cyclic codes with arbitrary number of generalized Niho type zeroes with corrigendum

Cyclic codes are an important class of linear codes, whose weight distri...
01/02/2022

A Bound on the Minimal Field Size of LRCs, and Cyclic MR Codes That Attain It

We prove a new lower bound on the field size of locally repairable codes...
02/09/2019

Skew-Polynomial Rings and Skew-Cyclic Codes

This is a survey on the theory of skew-cyclic codes based on skew-polyno...
08/30/2016

Lopsided Approximation of Amoebas

The amoeba of a Laurent polynomial is the image of the corresponding hyp...
08/22/2021

A universally consistent learning rule with a universally monotone error

We present a universally consistent learning rule whose expected error i...
08/09/2019

Cyclic Oritatami Systems Cannot Fold Infinite Fractal Curves

RNA cotranscriptional folding is the phenomenon in which an RNA transcri...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

In this paper we consider the schedulability of the Non-Cyclic Generalized Multiframe Task Model System Model defined by Moyo et al. [7] (nc-gmf in short). Moyo et al. provided a sufficient EDF schedulability test, Baruah extended the model by considering the Non-cyclic recurring task model [1] and provided an exact feasibility test. Stigge et al. further extend this model and consider Digraph real-time task model [8], and consider the feasibility (or, equivalently, the EDF-schedulability) of their task model.

Formally, an nc-gmf task set is composed of tasks . An nc-gmf task is characterized by the 3-tuple 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 time-instant .

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 design-time, it is non-cyclic. In this way this model generalizes the gmf model [2].

In this research we consider the scheduling of nc-gmf 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 nc-gmf using ftp schedulers. We report two first results: (i) we present and prove correct the critical instant for the nc-gmf then (ii) we propose an algorithm which provides a sufficient (but pseudo-polynomial) 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 non-cyclic 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 worst-case 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 nc-gmf.

Definition 2.

Let us consider an nc-gmf 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.

Figure 1: and .
Proof.

We111This 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 left-shift 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 left-shift 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 left-shift) 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

(a)(b)(c)(d)(e)
Figure 2: (a, b, c): Request bound functions (rbf) for a task with and . In (a): , in (b): , in (c): . (d): Maximum request bound functions (mrbf) (all the request bound functions are in light gray). (e): Maximum request bound function for task with and . The two oblique lines are and (using Equation 2).

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 nc-gmf task set is schedulable using an ftp assignment if, , the smallest positive solution to the equality

is not larger than .

Proof.

This is a consequence of Theorem 5 and the worst-case response time computation for ftp schedulers [9]. ∎

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 non-schedulability 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).

Data: , ,
1 ;
2 ;
3 while  not empty do
       ; // is ordered on
4       if  then
5             foreach  do
6                   ;
7                   ;
8                   if   then
9                         ;
10                        
11                  
12            
13      
14return mrbf;
Algorithm 1 Computing

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 left-most 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.

From Prop. 9, a point below will never be part of a scenario reaching , for the same reason that no scenario of starting at can ever reach . As is always above (Prop. 10), a point below will never be part of a scenario contributing in . ∎

From this last property, we can strongly improve Algorithm 1. As soon as a point is too far from mrbf, it can be ignored. Line 1 of Algorithm 1 can be re-written as:

(3)

With the same argument as in [8], we may prove that Algorithm 1 is polynomially bounded in and .

4 Open Questions and Conclusion

In this work, we provide a sufficient schedulability test for the scheduling of nc-gmf 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 non-cyclic recurring real-time task model. In Proceedings of the 2010 31st IEEE Real-Time Systems Symposium (2010), IEEE Computer Society, pp. 173–182.
  • [2] Baruah, S., Chen, D., Gorinsky, S., and Mok, A. Generalized multiframe tasks. Real-Time Systems 17, 1 (1999), 5–22.
  • [3] Fisher, N., and Baruah, S. A polynomial-time approximation scheme for feasibility analysis in static-priority systems with arbitrary relative deadlines. In Proceedings of the EuroMicro Conference on Real-Time 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 Real-Time 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 hard-real-time environment. Journal of the Association for Computing Machinery 20, 1 (January 1973), 46–61.
  • [6] Liu, J. W. S. Real-Time Systems. Prentice Hall, 2000.
  • [7] Moyo, N., Nicollet, E., Lafaye, F., and Moy, C. On schedulability analysis of non-cyclic generalized multiframe tasks. In 22nd Euromicro Conference on Real-Time Systems (2010), IEEE, pp. 271–278.
  • [8] Stigge, M., Ekberg, P., Guan, N., and Yi, W. The digraph real-time task model. In IEEE Real-Time 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 real-time tasks. Journal of Real-Time Systems 6, 2 (1994), 133–151.