Roadmap Introduction Concurrent Programming Communication and Synchronization Completing

Roadmap § Introduction § Concurrent Programming § Communication and Synchronization § § Completing the Java Model Overview of the RTSJ Memory Management Clocks and Time © Andy Wellings, 2004 § Scheduling and Schedulable Objects § Asynchronous Events and Handlers § Real-Time Threads § Asynchronous Transfer of Control § Resource Control § Schedulability Analysis § Conclusions

Scheduling and Schedulable Objects Lecture aims: § To give an overview of fixed priority schedule § To present the RTSJ Basic Scheduling Model © Andy Wellings, 2004

Introduction § Real-time systems must be able to interact with their § environment in a timely and predictable manner Designers must engineer analysable systems whose timing properties can be predicted and mathematically proven correct § Scheduling is the ordering of thread/process executions so that the underlying hardware resources (processors, networks, etc. ) and software resources (shared data objects) are efficiently and predictably used © Andy Wellings, 2004

Scheduling § In general, scheduling consists of three components an algorithm for ordering access to resources (scheduling policy) Ø an algorithm for allocating the resources (scheduling mechanism) Ø Ø a means of predicting the worst-case behaviour of the system when the policy and mechanism are applied (schedulability analysis or feasibility analysis) § Once the worst-case behaviour of the system has been predicted, it can be compared with the system’s timing requirements to ensure that all deadlines will be met © Andy Wellings, 2004

Fixed Priority Scheduling: Policy § FPS requires Ø statically allocating schedulable objects to processors Ø ordering the execution of schedulable objects on a single processor according to a priority Ø assigning priorities to schedulable objects at their creation time — although no particular priority assignment algorithm is mandated by FPS, it is usual to assign priorities according to the relative deadline of the schedulable object (relative to the schedulable object’s release time); the shorter the deadline, the higher the priority Ø priority inheritance when accessing resources © Andy Wellings, 2004

FPS: Mechanism and Analysis § Mechanism: FPS requires pre-emptive priority-based dispatching of processes — the processing resource is always given to the highest priority runnable schedulable object (allocated to that processor) § Feasibility analysis: There are many different techniques for analyzing whether a fixed priority-based system will meet its deadlines. Perhaps the most flexible is response time analysis © Andy Wellings, 2004

Information Needed for Analysis § Most approaches view the system as consisting of a § number of schedulable objects Each schedulable object is characterized by its Ø release profile Ø processing cost per release Ø other hardware resources needed per release Ø software resources per release Ø deadline Ø value © Andy Wellings, 2004

Release Profile § Typically after a schedulable object is started, it waits to be released (or may be release immediately) § When released it performs some computation and then waits to be released again (its completion time) § The release profile defines the frequency with which the releases occur; they may be time triggered (periodic) or event triggered § Event triggered releases are further classified into sporadic (meaning that they are irregular but with a minimum interarrival time) or aperiodic (meaning that no minimum interarrival assumptions can be made) © Andy Wellings, 2004

Processing cost per release § This is some measure of how much of the processor’s time § is required to execute the computation associated with the schedulable object’s release This may be a worst-case value or an average value depending on the feasibility analysis © Andy Wellings, 2004

Other resources § Hardware: (other than the processor) For networks, it is usually the time needed or bandwidth required to send the schedulable objects’ messages across the network Ø For memory, it is the amount of memory required by the schedulable objects (and if appropriate, the types of memory). Ø § Software resources: a list of the non shareable resources that are required and the cost of using each resource Access to non-shareable resources is a critical factor when performing schedulability analysis Ø Non shareable resources are usually non pre-emptible. Consequently when a schedulable object tries to acquire a resource it may be blocked if that resource is already in use Ø This blocking time has to be taken into account in any Ø © Andy Wellings, 2004

Deadline § The time which the schedulable object has to complete the § computation associated with each release As usually only a single deadline is given, the time is a relative value rather than an absolute value © Andy Wellings, 2004

Value § A metric which indicates the schedulable objects contribution to the overall functionality of the application. It may be Ø a very coarse indication (such as safety critical, mission critical, non critical), Ø a numeric value giving a measure for a successful meeting of a deadline, or Ø a time-valued function which takes the time at which the schedulable object completes and returns a measure of the value (for those systems where there is no fixed deadline) © Andy Wellings, 2004

Online versus Off-line Analysis § A key characteristic of schedulability (feasibility) analysis is § § whether the analysis is performed off-line or on-line For safety critical systems, where the deadlines associated with schedulable objects must always be met, off-line analysis is essential Other systems do not have such stringent timing requirements or do not have a predictable worst case behavior; here, on-line analysis may be appropriate or, the only option available These systems must be able to tolerate schedulable objects not being schedulable and offer degraded services Furthermore, they must be able to handle deadlines being missed or situations where the assumed worst-case loading scenario has been violated © Andy Wellings, 2004

The RTSJ Basic Model § The RTSJ provides a framework from within which on-line § § § feasibility analysis of priority-based systems can be performed for single processor systems The specification also allows the real-time JVM to monitor the resources being used and to fire asynchronous event handlers if those resources go beyond that specified by the programmer The RTSJ introduces the notion of a schedulable object rather than considering just threads A schedulable object is any object which implements the Schedulable interface © Andy Wellings, 2004

Schedulable Objects Attributes I § Release. Parameters Ø the processing cost for each release Ø its deadline Ø if the object is periodic or sporadic then an interval is also given Ø event handlers can be specified for the situation where the deadline is missed or the processing resource consumed is greater than the cost specified Ø There is no requirement to monitor the processing time consumed by a schedulable object © Andy Wellings, 2004

Schedulable Objects Attributes II § Scheduling. Parameters Ø an empty class Ø subclasses allow the priority of the object to be specified and, potentially, its importance to the overall functioning of the application Ø although the RTSJ specifies a minimum range of realtime priorities (28), it makes no statement on the allowed values of the importance parameter © Andy Wellings, 2004

Schedulable Objects Attributes III § Memory. Parameters Ø the maximum amount of memory used by the object in an associated memory area Ø the maximum amount of memory used in immortal memory Ø a maximum allocation rate of heap memory. § Processing. Group. Parameters Ø allows several schedulable objects to be treated as a group and to have an associated period, cost and deadline It should be noted that the RTSJ makes no mention of blocking time in any of the parameters associated with schedulable objects © Andy Wellings, 2004

The Schedulable Interface Three groups of methods § Methods which will communicate with the scheduler and will result in the scheduler either adding or removing the schedulable object from the list of objects it manages, or changing the parameters associated with the schedulable object Ø the scheduler performs a feasibility test on the objects it manages § Methods which get or set the parameter classes associated with the schedulable object Ø If the parameter object set is different from the one currently associated with the schedulable object, the previous value is lost and the new one will be used in any future feasibility analysis performed by the scheduler § Methods which get or set the scheduler © Andy Wellings, 2004

Schedulable Interface I package javax. realtime; public interface Schedulable extends Runnable { // example method resulting in feasibility being tested public boolean add. If. Feasible(); public boolean add. To. Feasibility(); public boolean remove. From. Feasibility(); public boolean set. If. Feasible( Release. Parameters release, Memory. Parameters memory); public boolean set. If. Feasible(Release. Parameters release, Memory. Parameters memory, Processing. Group. Paramters group. Parameters); public boolean set. Release. Parameters. If. Feasible( Release. Parameters release); public boolean set. Scheduling. Parameters. If. Feasible( Scheduling. Parameters sched); © Andy Wellings, 2004

Schedulable Interface II // methods which get/set the various parameter classes public Memory. Parameters get. Memory. Parameters(); public void set. Memory. Parameters(Memory. Parameters memory); public Processing. Group. Parameters get. Processing. Group. Parameters(); public void set. Processing. Group. Parameters( Processing. Group. Parameters group. Parameters); public Release. Parameters get. Release. Parameters(); public void set. Release. Parameters(Release. Parameters release); public Scheduling. Parameters get. Scheduling. Parameters(); public void set. Scheduling. Parameters( Scheduling. Parameters sched); © Andy Wellings, 2004

Schedulable Interface III // methods which get or set the scheduler public Scheduler get. Scheduler(); public void set. Scheduler(Scheduler scheduler, Scheduling. Parameters scheduling, Release. Parameters release, Memory. Parameters memory, Processing. Group. Parameters processing); } Both real-time threads and asynchronous event handlers implement this interface © Andy Wellings, 2004

Scheduler I package javax. realtime; public abstract class Scheduler { protected Scheduler(); . . . public abstract boolean set. If. Feasible( Schedulable schedulable, Release. Parameters release, Memory. Parameters memory); public abstract boolean set. If. Feasible( Schedulable schedulable, Release. Parameters release, Memory. Parameters memory, Processing. Group. Parameters group); public abstract void fire. Schedulable( Schedulable schedulable); public static Scheduler get. Default. Scheduler(); public abstract String get. Policy. Name(); public static void set. Default. Scheduler( Scheduler scheduler); } © Andy Wellings, 2004

Scheduler 2 package javax. realtime; public abstract class Scheduler {. . . protected abstract boolean add. To. Feasibility( Schedulable schedulable); public abstract boolean is. Feasible(); protected abstract boolean remove. From. Feasibility( Schedulable schedulable); } © Andy Wellings, 2004

The Priority Scheduler: Policy § Orders the execution of schedulable objects on a single § § processor according to a priority Supports a real-time priority range of at least 28 unique priorities (the larger the value, the higher the priority) Allows the programmer to define the priorities (say according to the relative deadline of the schedulable object) Allows priorities may be changed at run time Supports priority inheritance or priority ceiling emulation inheritance for synchronized objects (covered later) © Andy Wellings, 2004

The Priority Scheduler: Mechanism § Supports pre-emptive priority-based dispatching of schedulable § § § objects — the processing resource is always given to the highest priority runnable schedulable object Does not defined where in the run queue (associated with the priority level), a pre-empted object is placed; however, a particular implementation is required to document its approach Places a blocked schedulable object which becomes runnable, or has its priority changed at the back of the run queue associated with its (new) priority Places a thread which performs a yield operation at the back of the run queue associated with its (new) priority © Andy Wellings, 2004

The Priority Scheduler: Feasibility Analysis § Requires no particular analysis to be supported § Default analysis assumes an adequately fast machine © Andy Wellings, 2004

The Priority. Scheduler Class I public class Priority. Scheduler extends Scheduler { // fields public static final int MAX_PRIORITY; public static final int MIN_PRIORITY; // constructors protected Priority. Scheduler(); // methods which test feasibility protected boolean add. To. Feasibility( Schedulable schedulable); public boolean is. Feasible(); protected boolean remove. From. Feasibility( Schedulable schedulable); public boolean set. If. Feasible(Schedulable schedulable, Release. Parameters release, Memory. Parameters memory, Processing. Group. Parameters group); © Andy Wellings, 2004

The Priority. Scheduler Class II // other methods public void fire. Schedulable(Schedulable schedulable); public public int get. Max. Priority(); static int get. Max. Priority(Thread thread); int get. Min. Priority(); static int get. Min. Priority(Thread thread); int get. Norm. Priority(); static int get. Norm. Priority(Thread thread); String get. Policy. Name(); } © Andy Wellings, 2004

Summary I § Scheduling is the ordering of thread/process executions so § that the underlying hardware (processors, networks, etc. ) and software (shared data objects) resources are efficiently and predictably used The RTSJ has two types of schedulable objects: real-time threads and event handlers. The only scheduler guaranteed to be provided by an RTSJ implementation is a fixed priority scheduler (FPS) which has the following characteristics. © Andy Wellings, 2004

Summary II § Scheduling policy: FPS requires statically allocating schedulable objects to processors Ø ordering the execution of schedulable objects on a single processor according to a priority Ø assigning priorities to schedulable objects at their creation time Ø priority inheritance when accessing resources. Ø § Scheduling mechanism: FPS requires pre-emptive priority§ based dispatching of processes Feasibility analysis: The RTSJ does not mandate any particular schedulability analysis technique © Andy Wellings, 2004

Further Reading and Exercises © Andy Wellings, 2004