Compared with the clock-driven approach, the priority-driven scheduling approach has many advantages. They are

  • Easy to implement
  • Often have simple priority assignment rules
  • If the priority assignment rules are simple, the run-time overheads of maintaining priority queues can be small
  • Does not require information about deadlines and release times in advance so it is suited to applications with varying time and resource requirements

Despite its merits, the priority-driven approach has not been widely used in hard real-time systems, especially safety-critical systems. The main reason for this is that the timing behaviour of a priority-driven system is not deterministic when job parameters vary. Thus it is difficult to validate that the deadlines of all jobs scheduled in a priority-driven manner indeed meet their deadlines when job parameters vary.

Validation Problem:

Validation problem stated that for given a set of jobs, the set of resources available to the jobs, and the scheduling (and resource access-control) algorithm to allocate processors and resources to jobs, determine whether all the jobs meet their deadlines. This is a very difficult problem to solve if there is no all the information about all the jobs available in advance.

Consider a simple system of four independent jobs scheduled on two processors in a priority- driven manner with following characteristics.

  • There is a common priority queue and the priority order of jobs is J1, J2, J3, J4, with J1 being of highest priority.
  • It is a dynamic
  • Jobs may be preempted but never migrated to another
  • The release times, deadlines and execution times or the jobs are provided in the table.

Suppose we schedule the jobs according to their priorities and try out J2 with its maximum execution time 6 and also with its minimum execution time 2 shown in fig (a) and (b).

J4 is concerned, the worst-case schedule is (c) when execution time of J2 is 3 and J4 completes at 21 missing the deadline. The best-case schedule for J4 is (d) when J2 has execution time 5 and J4 completes at time 15.

This is known as a scheduling anomaly, an unexpected timing behaviour of priority-driven systems and difficult to validate the system in case of parity driven scheduling approach.