Scheduling Sporadic Jobs

Scheduling Sporadic Jobs

• Sporadic jobs have hard deadlines
• Minimum release times and maximum execution times
are unknown a priori
• No possibility to guarantee deadlines, when calculating
schedule off-line before system start
• However the properties of a sporadic job are known,
when the sporadic job is released
– Acceptance test (at start of frame):
• Sporadic job is only scheduled, if all scheduled jobs still meet their
deadlines
• Otherwise it is rejected
– Accepted sporadic jobs can be scheduled using EDF
 Sequence of Execution of Jobs
• First -> Periodic jobs
• Second -> Sporadic jobs
• Third -> Aperiodic jobs
 EDF Scheduling of the accepted Jobs
• Scheduler maintains a queue of accepted
sporadic jobs in increasing order of their
deadlines and inserts each newly accepted
sporadic job into this queue in this order.
• After periodic job execution, sporadic jobs
gets executed in order.
Example: frame size=4, shaded boxes are periodic tasks, S1, S2, S3, S4
are sporadic task with (d, e). Suppose at time 3 S1 is released
Time=3, d=17, e=4.5, total slack=4
Job rejected: Not sufficient slack (Slack = 4)!
 At time 5, d=29, e=4, total slack = 5.5
Job S2 accepted, put into sporadic job queue
 At time 11, S3 is released
Job S3 accepted, put before S2 into sporadic job queue
 At time 14, s4 is released
Job rejected: not enough slack!
Final execution of Sporadic jobs
 Optimality of Cyclic EDF
• Sporadic jobs are preemptive
• EDF is optimal if it is able to find a feasible
schedule of the job.
• But EDF is not optimal when it performs
acceptance test at arbitrary times i.e. at the
release of each sporadic job
 Practical Considerations
• Handling Frame Overruns
– Overruns may occur, when jobs execution time is
longer than maximum execution time
– Can be handled by
• abort the overrun job and report the premature
termination of the job
• unfinished portion may execute as aperiodic job in a
later frame
• continue to execute the overrun job
– but this may cause other jobs to be late, too!
 Practical Considerations
• Multiprocessor system
– Constructing a feasible schedule for multiprocessors is
more complex and time consuming than for
uniprocessors
– Since it is done off-line, exhaustive and complex
heuristic algorithms can be used