[RTEMS Project] #2795: Overrun Handling for general real-time models

[RTEMS trac]

#2795: Overrun Handling for general real-time models
-------------------------------------------------+-------------------------
 Reporter:  khchen                               |       Owner:
     Type:  enhancement                          |      Status:  new
 Priority:  high                                 |   Milestone:  4.11.1
Component:  cpukit                               |     Version:  4.11
 Severity:  critical                             |  Resolution:
 Keywords:  Overrun, RMS, SP, Scheduler,         |
  Periodicity                                    |
-------------------------------------------------+-------------------------

Comment (by kh.chen):

 Yes, as the utilization is over 100%, my test case has deadline misses
 definitely.
 However, the test case is designed on purpose to present what is the
 proper overrun handling within 30000 ticks.
 (Otherwise, domino effect will hide the enhancement in the worst case.)
 Please note that, '''Task 1 only executes 2 times''' in my test case.
 Let's only focus on the periodic behavior of task 2.

 Please refer to my paper [5]:
 [http://ls12-www.cs.tu-
 dortmund.de/daes/media/documents/publications/downloads/2016-wmc.pdf]
 In the following examples, the time unit is 1000 ticks. (1 = 1000 ticks)

 With the original design of overrun handing, there is only one postponed
 job and the release pattern is not periodic. As shown in Fig.2 (a) of [5],
 the arrival pattern from 16 is changed due to the lateness of the red job,
 by which the orange job and the following jobs are all released earlier.

 With this enhancement, the behaviour of task 2 with the enhancement is
 shown in Fig. 2 (b) of [5]. The postponed jobs due to the execution of
 task 1 are marked red. The jobs postponed due to the execution of previous
 jobs of task 2 are marked orange. The yellow job is postponed due to the
 orange job in the same period but can still finish its execution on time.

 In fact the example can be ''schedule'' if the system has dynamic real-
 time guarantees [3] for mixed-criticality system. Suppose that task 1
 requires a full timing guarantee with the abnormal execution time C_{1,A}
 = 6, and the normal execution time C_{1,N} = 1. Task 2 is a timing
 tolerable task with C_{2,A} = C_{2,N} = 1 as shown in Fig. 2 (c) of [5].
 The second job of task 1 needs 6 time units for its execution time due to
 fault detection and recovery. We can see that after all the postponed jobs
 of task 2 are finished at 24, the release of task 2 turns back according
 to the original periodic pattern again. Since this example is a bit
 complicated for normal users, I didn't implement it in the example case.

 In my patch. I automatically '''restart the watchdog''' in case of a
 timeout and '''keep updating the number of postponed jobs''' (increase).
 If the number of postponed jobs is not 0, the default scheduler will
 decrease the number of postponed jobs and release the postponed jobs
 accordingly. Please note that, '''the deadline of watchdog is not updated
 by the job releasing unless the targeted task has no more postponed
 jobs.'''

 We all know that the schedulbility researches always talking about WCET
 and the worst case rarely happens in reality. However the overrun handling
 is still useful to isolate the effect of the abrupt overrun without
 disturbing the other normal tasks.

--
Ticket URL: <http://devel.rtems.org/ticket/2795#comment:3>
RTEMS Project <http://www.rtems.org/>
RTEMS Project