1

In the effort of trying to understand a fixed priority scheduling scheme, such as Deadline Monotonic schedulers, amidst the horribly written definitions online -- I'm trying to schedule an example task set with that policy, in which I require that the execution of tasks is non-preemptive. This means that I have the following assumptions:

  1. When a task begins executing, it cannot be stopped by any other task, so the former must finish
  2. The tasks in the task set are released periodically (according to period Ti)
  3. All tasks are first released at time t=0
  4. Each task task_i has a fixed computation time Ci
  5. Each task task_i has a relative deadline Di, which is relative to the time in which the task came in (was released)

Assume I have this task set:

  • Task 1: C1 = 1, D1 = 2, T1 = 3
  • Task 2: C2 = 1, D2 = 5, T2 = 5
  • Task 3: C3 = 2, D3 = 5, T3 = 5

According to the exact schedulability test based on worst case response time analysis from Theorem 15 by George et al., the task set is in fact schedulable.

To create the schedule for a supposed interval of time [0, 10], this means that:

  • Task 1 becomes available at the instances: 0, 3, 6, 9
  • Task 2 becomes available at the instances: 0, 5, 10
  • Task 3 becomes available at the instances: 0, 5, 10

With deadline monotonic scheduling, we already know that task_1 >= task_2 >= task_3 according to priority, since the deadline of task_1 <= that of task_2 <= that of task_3.

I will first try to formulate the schedule for each discrete interval, and then ask a follow-up question on the problematic interval:

# interval  ->  executing task
[0, 1] -> task_1
[1, 2] -> task_2
[2, 3] -> task_3
[3, 4] -> task_3
[4, 5] -> task_1
[5, 6] -> task_2
[6, 7] -> I THINK, task_1

So at instance t=6, two tasks are ready: task_1 and task_3. Is it correct that task_1 should get the priority and execute between instances 6 and 7 -- or should task_3 execute since we always do: task_1 then task_2 then task_3?

If it is the case that the higher priority task would execute, then wouldn't this imply that we HAVE to re-sort a queue of pending tasks every time a new task arrives?

If so, doesn't that defy the purpose and then a fixed priority scheduler would actually be dynamic in nature?

Mo Kanj
  • 107
  • 7
  • 1
    A priority scheduler is always a form of sorting. In the simplest case, the dispatcher merely chooses the task at the head of a sorted (priority) queue. When a task becomes runnable, it is inserted in the priority queue in order. Now, it happens that with a small number of priorities, you can use fancy cpu instructions on a bitfield to detect the next highest priority task, thus the O(n) insertion time becomes O(1), but that is a special purpose hack, not a general implementation. – mevets Apr 26 '22 at 12:52
  • @mevets So I guess that the (re-sorting) and selection of the next available task with highest priority has to be done after every task has finished executing? – Mo Kanj Apr 26 '22 at 12:58
  • Yes, the selection is generally O(1) -- even with a simple priority-q, it is just removing the head. The insertion would be O(n); but could be worked around. It is possible to encode a table with the activations so that the dispatch merely went `for (i = 0; ; i = (i + 1) % NTAB) { Dispatch(tab[i]); }` where tab[i] encodes the schedule you have above. It would be a tidy implementation, while equivalent to priority encoding, thus theory. – mevets Apr 26 '22 at 13:45

0 Answers0