cannot finish before the task on unit u j1 as all tasks are ordered according to their
finishing time.
If the task time including T u + T r of this task is still smaller than
T compl.i + (T u + T r ) (line b2) then the idle time of this task is considered as too long
or in other words the performance impact would be too high, and thus a new user
task is assigned to u j .
Of course, the finishing time of u j has to be adapted as well. In the next step, the
just updated u j must be placed at the correct position in all units to restore the
ordering property.
For the cases where we still have no decision whether a test should be performed
synchronously or asynchronously, i.e., t i + T ad − (T u + T r )
t i + 1 < t i + T ad , the
decision is made easy.
If enough time is available to perform the testing asynchronously it is done so,
otherwise synchronously (step 5 of Fig. 7.6).
Even if u i+1 is scheduled for synchronous testing and has to be included in set R,
the time overheads will be less than with asynchronous testing but more waiting
takes place.
We just illustrated the algorithm on the example of two threads. The algorithm
T1 in Fig. 7.6, however, was extended to support n units. It is also explained below
why not the true completion times of the tasks are used but an approximation
instead.
A still unanswered question is when the synchronous diagnosis of R [ U2,
should be performed. If possible, the tests for these units are executed within the
gaps between the asynchronous diagnosis of the units U1\R, when the gaps are
larger than T sd . If not enough gaps are available; the synchronous diagnosis could
Fig. 7.7 Task example 1
80
7 Testing, Checking, and Hardware Syndrome
finishing time.
If the task time including T u + T r of this task is still smaller than
T compl.i + (T u + T r ) (line b2) then the idle time of this task is considered as too long
or in other words the performance impact would be too high, and thus a new user
task is assigned to u j .
Of course, the finishing time of u j has to be adapted as well. In the next step, the
just updated u j must be placed at the correct position in all units to restore the
ordering property.
For the cases where we still have no decision whether a test should be performed
synchronously or asynchronously, i.e., t i + T ad − (T u + T r )
t i + 1 < t i + T ad , the
decision is made easy.
If enough time is available to perform the testing asynchronously it is done so,
otherwise synchronously (step 5 of Fig. 7.6).
Even if u i+1 is scheduled for synchronous testing and has to be included in set R,
the time overheads will be less than with asynchronous testing but more waiting
takes place.
We just illustrated the algorithm on the example of two threads. The algorithm
T1 in Fig. 7.6, however, was extended to support n units. It is also explained below
why not the true completion times of the tasks are used but an approximation
instead.
A still unanswered question is when the synchronous diagnosis of R [ U2,
should be performed. If possible, the tests for these units are executed within the
gaps between the asynchronous diagnosis of the units U1\R, when the gaps are
larger than T sd . If not enough gaps are available; the synchronous diagnosis could
Fig. 7.7 Task example 1
80
7 Testing, Checking, and Hardware Syndrome