5.4 A PERIODIC R EQUESTS
5.4.4 Acceptance Test
under the capacity, for it is the task instance with the shortest deadline. At time 4, it is completed and the time allocated for its exception part is added to Γ1, which is still the highest priority entity. Task τ2 runs under that capacity until time 6 and accrues a capacity Γ2 = 2. At time 6, the server capacity ΓS is replenished, another instance of τ1 is released, and an instance of the communication task arrives. ΓS is the highest priority entity at that time, and according to our policy, the communication task is selected to run under that capacity. So, by time 7, ΓS is exhausted and the communication task completed. Now, the highest priority entity is τ1, which is executed consequently. When τ1 is completed at time 10, the time allocated for its exception part is added to capacity Γ1, which at once becomes the highest priority entity. The execution of τ2 is continued for 1 time unit under Γ1 so that Γ2 increases to 3. From time 11 to 12, Γ2 is the highest priority entity and τ2 is executed under it until it becomes faulty. At the same time, the next instance of τ1 is released. This instance is now the highest priority entity and is executed until time 15, when it becomes faulty. Its exception part, which is added to the pending queue at that moment, immedi-ately becomes the highest priority entity and is executed accordingly. After the exception part is completed, Γ2 becomes the highest priority entity again. The only pending task in-stance is the faulty main part of τ2, which is executed under the capacity until time 17. At that time, the next instance of τ1 is released and another aperiodic request arrives. As Γ2 is still the highest priority entity, the aperiodic request is executed under it and completed by time 19. After Γ2’s being exhausted, τ1 is selected for execution. At time 22, when it be-comes faulty, its exception part is added to the pending and immediately executed. After the exception part is completed, the exception part of τ2 is run.
This example illustrates how the mechanism of priority exchange allows preserving the capacities in the system: The last time a new capacity is added is at time10, when τ1 is completed and the time allocated for the execution of its exception part is turned into a capacity. The capacities are still available from time 16 to 18 to execute the faulty main part of τ1 and at time 18 to execute the communication task. This instance of the communi-cation task is served immediately, even though the last capacity was added at time 10. Ac-tually, the last replenishment of the server capacity occurred even earlier at time 6.
{Ji,k | i ∈ 1..n, k ≥ 1} be an arbitrary set of instances of the task pairs in T. We define for each i ∈ 1..n and k ≥ 1 a job J'i,k that has the same release time and deadline as Ji,k and an actual execution time C'i,k defined as follows:
>
+
= ≤
i k i k i i
i k i k i k
i C E C C
C C C C
, ,
, ,
, ,
: ,
' ,
where Ci,k > 0 and Ei,k > 0 are the actual execution times of the main part and exception part of Ji,k respectively. Since for all J'i,k, C'i,k ≤ Ci + Ei, they can be considered as the in-stances of the tasks τ'i ∈ T '. Hence, the IPE server feasibly schedules the job set {J'i,k | i ∈ 1..n, k ≥ 1} for any additional load of aperiodic requests. Let σ' denote the schedule that the IPE server produces for that job set and σ be the schedule produced by TAFT-IPE, both for the same aperiodic load. We show that σ meets each of the three conditions of Definition 5-1.
First, note that at the same time when EPi,k is added to the pending queue, MPi,k is turned into an aperiodic request (lines 70-72) so that throughout the ready time of Ji,k exactly one of both is part of the pending queue as a periodic instance. As furthermore Ji,k and J'i,k have the same release time and deadline by construction, it follows that MPPi,k (denoting MPi,k
as long as it is periodic) and EPi,k get as much resources in σ as J'i,k in σ', and get them by the same time as well. Actually, since we do not generally give highest priority to aperi-odic requests under capacities, periaperi-odic instances may be served even earlier in σ than in σ'. Therefore we state that for each time t prior to the completion of either EPi,k or MPi,k
cσ(MPPi,k,t) + cσ(EPi,k,t) ≥ cσ'(J'i,k,t) (1)
where for a schedule σ an entity e and a time t, cσ(e,t) denotes the time allocated to e in σ by time t. Furthermore, since EPi,k is inserted into the pending queue and MPi,k turned into an aperiodic request immediately after running MPi,k for Ci, we observe that
∀t cσ(MPPi,k,t) + cσ(EPi,k,t) ≥ Ci ⇒ cσ(MPPi,k,t) = Ci (2) For each instance Ji,k, we distinguish two cases:
1. Ci,k ≤ Ci. It follows that C'i,k = Ci,k. Due to the feasibility of σ', ∃t ≤ di,k : cσ'(J'i,k,t) = C'i,k. Together with (1) and (2), this implies that MPi,k completes no later than t in σ. Furthermore, this implies that EPi,k is never put into the pending queue. So, the conditions (1) – (3) of Definition 5-1 are fulfilled.
2. Ci,k > Ci. It follows that C'i,k > Ci. Due to the feasibility of σ', ∃t ≤ di,k: cσ'(J'i,k,t) = Ci. Together with (1) and (2), this implies that ∃t' ≤ t: cσ(MPi,k,t') = Ci. At t', MPi,k is turned into an aperiodic request and EPi,k is added to the pending queue. Due to the feasibility of σ', there is a first time t'' < di,k: cσ'(J'i,k,t) > Ci. Due to (1) and (2), ∃t+ ≤ t'' such that either MPi,k is completed before t+ or cσ(EPi,k,t+) > 0.
a. In the first case, MPi,k is completed before t+ < t'' < di,k. Furthermore, at that time, EPi,k is removed from the pending queue, so that ∀x > t+: not run-ning(EPi,k,x).
b. In the second case, t+ is the start time of EPi,k. Since MPi,k is aborted when EPi,k
starts running, it follows that not completes(MPi,k) and ∀x > t+: not run-ning(MPi,k, x). Furthermore, due to the feasibility of σ', ∃t* ≤ di,k : cσ'(J'i,k,t*) = C'i,k = Ci + Ei,k, which together with (1) and (2) implies that EPi,k is completed by t*.
In both cases, a. and b., the condition (1) – (3) of Definition 5-1 are fulfilled.
Theorem 5-2 TAFT-IPE guarantees timely completion of correct jobs and exception han-dling for a set T := {τi = (Ti,Ci,Ei) | i ∈ 1..n} of periodic task pairs if the utilization factor
1 :
1
+ ≤
=
∑
= n
i i
i i
T E
U C .
Proof The theorem is a direct implication of Lemma 5-1 and the schedulability condition of the IPE server (Stankovic et al. 1998 p. 189).
5.4.4.2 Acceptance Test for Aperiodic Requests
The acceptance test is performed for each instance of a communication task to provide predictability on a per request basis. After passing the acceptance test, a request is guaran-teed to be completed by its deadline; requests that do not pass the acceptance test are not executed. This ensures that the execution service does not exhibit timing failures, thus meeting the assumptions of our system model (cf. Section 4.2).
As the acceptance test is performed for every instance of a communication task it must be efficient. Therefore, instead of devising a complex exact test, we provide a sequence of simple sufficient criteria. These criteria are evaluated in order of increasing complexity. As soon as the first sufficient criterion is true, the request is accepted. If none of the criteria evaluates to true, the request must be rejected, since its timely completion cannot be guar-anteed based on the acceptance test.
In the presentation of the criteria, C and D are the worst-case execution time and relative deadline of the request respectively, and d := t + D is its absolute deadline, where t is the time at which the test is performed. Each of the following tests decrements the value of C.
They require that C after being decrementing is less than or equal to zero, which means that there are sufficient capacities in the system to complete the request by its deadline.
1. If the current entity 'cur_ent' is a capacity Γ and C – min(Γ,rnext – t) ≤ 0;
If the current entity is a capacity, it is allocated to the request, at least until either the next task instance is released (rnext – t) or the capacity is exhausted (Γ).
2. C'1 := C – ΓS ≤ 0;
If the server has a capacity at time t, it can be allocated to the request immediately.
3. C'2 := C'1 –
∑
d ≤dΓii ≤ 0 , where di is the deadline associated with Γi;
All capacities with deadlines not greater than d can be allocated to the request.
4. C'3 := C'2 –
∑
t<H+e<d ∆i − − ii d H e
' min( , ' )≤ 0, whereH :'=H
t/H
is the starting time of the current hyper period;The request can use all server capacity replenishments that take place during [t,d], but only during [ ,d], where is the time at which the replenishment oc-curs.
ei
H'+ H'+ei
In the actual implementation, rather than computing the sum first and then subtracting it from C, it is better to iteratively decrement C and stop as soon as the criterion is verified.
As we assume that C is small as compared to the execution times and periods of the peri-odic tasks, we suppose that one of the first criteria will yield a decision in many cases.
A practical approach to increase the probability that a request can be accepted is to give the communication tasks a higher priority than the main parts, but a lower priority than the exception parts. This means that the communication tasks can run not only under capaci-ties, but also during the times allocated for the main parts. The price to be paid for this improvement is losing the guarantee that main parts are completed as long as they do not exceed their specified resource demand. This may be acceptable for certain applications for the following reasons:
• The fact that main parts may not be completed does not raise a new systematic problem, but is already part of the underlying concept. So, the suggested approach has mainly a quantitative impact in that it reduces the probability that main parts are completed. In particular, a timely completion of the exception parts would still be guaranteed.
• The execution times of the communication tasks are small as compared to those of the application tasks. Hence, even if the same main part is preempted several times, this will not lead to a significant reduction of its allocated execution time. There-fore, the mentioned quantitative impact appears to be limited.