Roadmap

1. Introduction Concurrent Programming Communication and Synchronization Completing the Java Model Overview of the RTSJ Memory Management Clocks and Time Scheduling and Schedulable Objects Introduction to fixed priority scheduling Overview of the RTSJ model Continued Asynchronous Events and Handlers Real-Time Threads Asynchronous Transfer of Control Resource Control Schedulability Analysis Conclusions Roadmap

2. Scheduling and Schedulable Objects Lecture aims • To review the parameter classes in detail • To consider alternative schedulers

3. The Parameter Classes • Each schedulable objects has several associated parameters • These parameters are tightly bound to the schedulable object and any changes to the parameters can have an immediate impact on the scheduling of the object or any feasibility analysis performed by its scheduler • Each schedulable object can have only one set of parameters associated with it • However, a particular parameter class can be associated with more than one schedulable object • In this case, any changes to the parameter objects affects all the schedulable objects bound to that parameter

4. Release Parameters I • Release parameters characterize • how often a schedulable object runs • the worst case processor time needed for each run • a relative deadline by which each run must have finished • There is a close relationship between the actions that a schedulable object can perform and its release parameters • E.g., the RealtimeThread class has a method called waitForNextPeriod; however a real-time thread object can only call this methods if it has PeriodicParameters associated with it • This may seem a little counter intuitive; the main advantage of is that it allows a thread to change its release characteristics and hence adapt its behavior

5. The ReleaseParameter Class public class ReleaseParameters { protected ReleaseParameters(); protected ReleaseParameters(RelativeTime cost, RelativeTime deadline, AsyncEventHandler overrunHandler, AsyncEventHandler missHandler); public RelativeTime getCost(); public AsyncEventHandler getCostOverrunHandler(); public RelativeTime getDeadline(); public AsyncEventHandler getDeadlineMissHandler(); // methods to set the above public booleansetIfFeasible(RelativeTime cost, RelativeTime deadline); }

6. Release Parameters II • The minimum information that a scheduler will need for feasibility analysis is the cost and deadline • cost: a measure of how much CPU time the scheduler should assume that the scheduling object will require for each release • This is dependent on the processor on which it is being executed; consequently, any programmer-defined value will not be portable • deadline: the time from a release that the scheduler object has to complete its execution • overrunHandler: the asynchronous event handler that should be released if the schedulable object overruns its cost value on a particular release • missHandler is released if the schedulable object is still executing when its deadline arrives

7. Cost Enforcement If cost monitoring is supported: • the RTSJ requires that the priority scheduler gives a schedulable object a CPU budget of no more than its cost value on each release • if a schedulable objects overrun its cost budget, it is automatically descheduled (made not eligible for execution) immediately • it will not be re-scheduled until either its next release occurs (in which case its budget is replenished) or its associated cost value is increased.

8. The PeriodicParameters Class • For schedulable objects which are released on a regular basis • The start time can be an AbsoluteTime or a RelativeTime and indicates when the schedulable object should be first released • For a real-time thread, the actual first release time is given by • if start is a RelativeTime value Time of invocation of start method + start • if start is an AbsoluteTime value Max of (Time of invocation of start method, start) • A similar formula can be given for an asynchronous event handler • The deadline for a schedulable object with periodic parameters is measured from the time that it is released not when it is started or fired

9. The PeriodicParameters Class package javax.realtime; public class PeriodicParametersextends ReleaseParameters { // constructors public PeriodicParameters( HighResolutionTime start, RelativeTime period, RelativeTime cost, RelativeTime deadline, AsyncEventHandler overrunHandler, AsyncEventHandler missHandler); // methods public RelativeTime getPeriod(); public HighResolutionTime getStart(); public void setPeriod(RelativeTime period); public void setStart(HighResolutionTime start); public booleansetIfFeasible(RelativeTime period, RelativeTime cost, RelativeTime deadline); }

10. The AperiodicParameters Class I public class AperiodicParameters extends ReleaseParameters { // constructors public AperiodicParameters( RelativeTime cost, RelativeTime deadline, AsyncEventHandler overrunHandler, AsyncEventHandler missHandler); public booleansetIfFeasible(RelativeTime cost, RelativeTime deadline); ... } The deadline of an aperiodic schedulable object can never be guaranteed, why? Hence, the deadline attribute should be interpreted as a target completion time rather than a strict deadline.

11. The AperiodicParameters Class II • Schedulable object with aperiodic parameters are released at irregular intervals • When an aperiodic schedulable object is released for the first time, it becomes runnable and is scheduled for execution. • Before it completes its execution, it may be released again. • It is necessary for an implementation to queue the release events to ensure that they are not lost • The programmer is able to specify the length of this queue and the actions to be taken if the queue overflows

12. The AperiodicParameters Class III public class AperiodicParameters extends ReleaseParameters { ... public static final String arrivalTimeQueueOverflowExcept; public static final String arrivalTimeQueueOverflowIgnore; public static final String arrivalTimeQueueOverflowReplace; public static final String arrivalTimeQueueOverflowSave; ... }

13. The AperiodicParameters Class IV public class AperiodicParameters extends ReleaseParameters { ... public String getArrivalTimeQueueOverflowBehaviour(); public void setArrivalTimeQueueOverflowBehaviour( String behaviour); public intgetArrivalTimeQueueOverflowLength(); public void setArrivalTimeQueueOverflowLength( int initial); }

14. Sporadic Parameters • Schedulable object with sporadic parameters are released at irregular intervals but the scheduler can assume that two releases will always occur greater than or equal to a minimum inter-arrival time • At run time, the scheduler must check for violation of this constraint and take some corrective action • When a sporadic schedulable object is released for the first time, it becomes runnable and is scheduled for execution. • Before it completes its execution, it may be released again. • As with aperiodic schedulable objects, it is necessary for an implementation to queue the release events to ensure that they are not lost

15. The SporadicParameters Class I publicclassSporadicParameters extends AperiodicParameters { public static final String mitViolationExcept; public static final String mitViolationIgnore; public static final String mitViolationReplace; public static final String mitViolationSave;

16. The SporadicParameters Class II //constructors public SporadicParameters(RelativeTime minInterarrival, RelativeTime cost, RelativeTime deadline, AsyncEventHandler overrunHandler, AsyncEventHandler missHandler); // methods public StringgetMitViolationBehaviour(); public voidgetMitViolationBehaviour(String behaviour); public RelativeTime getMinimumInterarrival(); public void getMinimumInterarrival ( RelativeTime interval); public booleansetIfFeasible( RelativeTime interarrival, RelativeDeadline cost, RelativeTime deadline); }

17. Example I • Consider a sporadic event handler which is released by a call to the fire method of its associated asynchronous event • Suppose that the maximum length of the queue is 3 and the implementation is simply keeping track of the time of the fire request • Assume the MIT is 2 • At some point in time the queue is:

18. Example II • Consider a new event occurring at X+12: • throw an exception: ResourceLimitError is thrown on the offending call of the fire method; note that even if more than one handler is associated with the event, the exception is thrown if one or more of them suffer a queue overflow • ignore the fire: the call to fire the asynchronous event is ignored for that handler • replace the last release: the last release event is overwritten with the new release event. X X+4 X+12 • save the request: the queue is lengthened.

19. Example III • The available actions on violation of the minimum inter-arrival time are similar (assume a new requests arrives at X+5) • throw an exception: the exception MITViolationException is thrown on the offending call of the fire method • ignore the fire: the call to fire the event is ignored • replace the last request: the last request is overwritten with the new request; the new queue becomes • save the request: the request is saved but the time between the request is set to the minimum inter-arrival time: note: the deadline of the last release is still relative to X+5

20. Scheduling Parameters public abstract class SchedulingParameters { // constructors public SchedulingParameters(); }

21. Priority Parameters publicclassPriorityParameters extends SchedulingParameters { // constructors public PriorityParameters(int priority); // methods public int getPriority(); public void setPriority(int priority); public String toString(); }

22. Importance Parameters public class ImportanceParameters extends PriorityParameters { // constructors public ImportanceParameters( int priority, int importance); // methods public int getImportance(); public void setImportance(int importance); public jString toString(); }

23. Processing Group Parameters • See specification

24. Alternative Schedulers • Most RT OSs support fixed priority pre-emptive based scheduling with no online feasibility analysis • As more computers become embedded, there is need for more flexible scheduling • In general, there are three approaches to getting flexible scheduling: • Pluggable scheduler: the system provides a framework from within which different schedulers can be plugged in • Application-defined schedulers: the system notifies the application every time an event occurs which requires a scheduling decision to be taken; the application then informs the system which thread should execute next • Implementation-defined schedulers: an implementation is allowed to define alternative schedulers; typically this would require the underlying operating system (virtual machine, in the case of Java) to be modified

25. RTSJ and Alternative Schedulers • The RTSJ adopts the implementation-defined schedulers approach • Applications can determine dynamically whether the real-time JVM on which it is executing has a particular scheduler • This is the least portable approach, as an application cannot rely of any particular implementation-defined scheduler being supported

26. Flexible Scheduling and Priority-based Systems • Priority-based scheduling is very flexible if schedulable objects can change their priority (as they can in the RTSJ) • Much can be done which is portable by allowing the application to implement its own scheduling policy on top of the PriorityScheduler

27. EDF Scheduler PriorityScheduler EDFScheduler public EdfScheduler( int , int , int , int ) // low,medium, high, maxSchedObjects public synchronized void deschedule() public synchronized void reschedule() protected synchronized boolean addToFeasibility(Schedulable) public synchronized boolean changeIfFeasible(Schedulable, ReleaseParameters MemoryParameters) public synchronized void fireSchedulable(Schedulable) public synchronized boolean isFeasible() protected synchronized boolean removeFromFeasibility(Schedulable) public java.lang.String getPolicyName()

28. EDF Scheduler Approach I • All objects which are to be scheduled by the EdfScheduler run at one of three priority levels: low, medium and high • When schedulable objects are released, they are released at the high priority level; they immediately call the reschedule method to announce themselves to the EdfScheduler • The EdfScheduler keeps track of the schedulable object with the closest absolute deadline; this object has its priority set to the medium level • When a call is made to reschedule, the EdfScheduler compares the deadline of the calling object with that of its closest deadline; if the caller has a closer deadline, the object with the current closest deadline has its priority set to low and the caller has its priority set to medium

29. EDF Scheduler Approach II • After the end of each release, a schedulable object calls deschedule • The EdfScheduler sets caller’s priority to high (ready for the next release), and then scans its list of schedulable objects to find the one with the closest deadline • It sets the priority of this object to medium • The constructor for the class gives the appropriate priority values for low, medium and high • It also contains the maximum number of schedulable objects to be scheduled by the scheduler

30. EDF Example I • Consider the execution of three real-time threads (T1, T2 and T3) which are released at times t1, t2, and t3 respectively (where t1 < t2 < t3) • T2 has the closest deadline, followed by T3 and T1.

31. EDF Example II call to deschedule priority call to reschedule High T1 T2 T3 Medium T1 T2 T1 T3 Low T1 T1 T1, T3 time t1 t2 t3 Running T1 T2 T3 T2 T3 T1 thread

32. EDF Example III • With this approach, a thread with a longer deadline will execute in preference to a shorter deadline thread but only for a small limited time when it is released • This can be ensured by encapsulating the calls to reschedule and deschedule

33. EDF Example IV

34. Summary • The parameter classes capture the properties which affect scheduling • The RTSJ provides a framework for alternative implementation-defined schedulers

35. Further Reading and Exercises