![Memory Management
Memory Management
12
public int match(final int with[][]) {
LTMemory myMem = new LTMemory(1000, 5000); // scoped memory
int found = 0;
for(int i=0; i < table.length; i++) {
myMem.enter(new Runnable()
{
public void run() {
int[][] product = dotProduct(table[i], with);
if(equals(product, unity)) found++;
}
});
}
}
return found;
}](https://image.slidesharecdn.com/rtjava-250109165754-b62cb325/85/Reliable-and-Concurrent-Software-RT-Java-12-320.jpg)
Reliable and Concurrent Software - RT Java
- 1. Reliable and Concurrent Software Reliable and Concurrent Software Real-Time Java Real-Time Java PDEEC 2009/2010 1
- 2. Real-Time Java Real-Time Java Context ◦ In the beggining Java was not considered for real-time Due to both predictability and efficiency issues Sporadically it was used in the non-real-time part of real-time systems Or with hardware support ◦ First efforts by 3 different groups NIST and NewMonics (PERC); SUN; IBM (Greg Bollella) Merged and made a requirements analysis in 1999 ◦ RT Java was the first Java Specification Request (JSR-001) A group of experts was formed to produce a specification (led by Greg Bollella), and a reference implementation (Timesys) Definition was in 2000, being revised for a long, long time (JSR 282) ◦ A separate approach was followed by the J-Consortium (led by Kevin Nielson) Proposed changes to the JavaVM which was unacceptable to Sun Did not succeed ◦ Currently there are several slightly different implementations (Sun, IBM, Aonix(Atego), …) 2
- 3. Real-Time Java Real-Time Java The RTSJ enhances Java in the following areas: ◦ memory management ◦ time values and clocks ◦ schedulable objects and scheduling ◦ real-time threads ◦ asynchronous event handling and timers ◦ asynchronous transfer of control ◦ synchronization and resource sharing 3
- 4. Memory Management Memory Management Many real-time systems have only a limited amount of memory available because of ◦ the cost ◦ other constraints associated with the surrounding system (e.g., size, power or weight constraints) It is necessary to control how this memory is allocated so that it can be used effectively Where there is more than one type of memory (with different access characteristics), it may be necessary to instruct the compiler to place certain data types at certain locations By doing this, the program is able to increase performance and predictability as well as interact with the outside world 4
- 5. Memory Management Memory Management The run-time system of most languages provide two data structures to help manage dynamic memory: the stack and the heap In Java, the stack is typically used for storing variables of basic data types (such as int, boolean and reference variables) which are local to a method All objects, which are created from class definitions, are stored on the heap. 5
- 6. Memory Management Memory Management The JVM is responsible for managing the heap Key problems are deciding how much space is required and when allocated space can be released The latter can be handled in several ways, including: ◦ 1. require the programmer to return the memory explicitly — this is error prone but is easy to implement ◦ 2. require the JVM to monitor the memory and determine when it can logically no longer be accessed ◦ 3. require the JVM to monitor the memory and release chunks which are no longer being used (garbage collection); this is, perhaps, the most general approach as it allows memory to be freed even though its associated access type is still in scope 6
- 7. Memory Management Memory Management From a real-time perspective, the approaches have an increasing impact on the ability to analyse the timing properties of the program Garbage collection may be performed either when the heap is full or by an incremental activity In either case, running the garbage collector may have a significant impact on the response time of a time-critical thread 7
- 8. Memory Management Memory Management Consider a time-critical periodic thread which has had all its objects pre-allocated Even though it may have a higher priority than a non time-critical thread and will not require any new memory, it may still be delayed if it preempts the non time-critical thread when garbage collection has been initiated by an action of that thread In this instance, it is not safe for the time-critical thread to execute until garbage collection has finished (particularly if memory compaction is taking place) Although there has been much work on real-time garbage collection and progress continues to be made, there is still a reluctance to rely on these techniques in time-critical systems 8
- 9. Memory Management Memory Management The RTSJ provides memory management which is not affected by the vagaries of garbage collection It defines memory areas, some of which exist outside the traditional Java heap and never suffer garbage collection RTSJ requires that the garbage collector can be preempted by some real-time threads and that there should be a bounded latency for preemption to take place The MemoryArea class is an abstract class from which for all RTSJ memory areas are derived When a particular memory area is entered, all object allocation is performed within that area 9
- 10. Memory Management Memory Management HeapMemory allows objects to be allocated in the Java Heap ImmortalMemory is shared among all threads; objects created here are never subject to garbage collection and are freed only when the program terminates ScopedMemory is a memory area for objects that have a well-defined lifetime; associated with each scoped memory is a reference count which keeps track of how many real-time entities are currently using the area ◦ When the reference count goes from 1 to 0, all objects resident in the scoped memory have their finalization method executed and the memory is reclaimed 10
- 11. Memory Management Memory Management 11 public abstract class MemoryArea { protected MemoryArea(long sizeInBytes); protected MemoryArea(long sizeInBytes, Runnable logic); ... // methods public void enter(); // Associate this memory area to the current // schedulable object for the duration of the // logic.run method passed as a parameter to // the constructor public void enter(Runnable logic); // Associate this memory area to the current // schedulable object for the duration of the // logic.run method passed as a parameter
- 12. Memory Management Memory Management 12 public int match(final int with[][]) { LTMemory myMem = new LTMemory(1000, 5000); // scoped memory int found = 0; for(int i=0; i < table.length; i++) { myMem.enter(new Runnable() { public void run() { int[][] product = dotProduct(table[i], with); if(equals(product, unity)) found++; } }); } } return found; }
- 13. Memory management Memory management Because a scoped memory area could be reclaimed at any time, ◦ it is not permitted for a memory area with a longer lifetime to hold a reference to an object allocated in a memory area with a shorter lifetime. This means that heap memory and immortal memory cannot hold references to objects allocated in scoped memory. ◦ Nor can one scoped memory area hold a reference to an object allocated in a lower (more deeply nested) memory area. 13
- 14. Clocks andTime Clocks andTime Standard Java only supports the notion of a wall clock (calendar time) We have seen that real-time systems require extra features In RTSJ, HighResolutionTime encapsulates time values with nanosecond granularity A value is represented by a 64 bits milliseconds and a 32 bits nanoseconds component The class is an abstract class which has three subclasses: AbsoluteTime: expressed as a time relative to some epoch.This epoch depends of the associated clock. It might be January , 1970, GMT for the wall clock or system start-up time for a monotonic clock RelativeTime: Interval of time. RationalTime is a relative-time type which has an associated frequency. It is used to represent the rate at which certain events occur (for example, periodic thread execution – an interval of 1 second and a frequency of 100 means blocks of 10 milliseconds, if no frequency is given 1000 milliseconds is assumed.) 14
- 15. Clocks andTime Clocks andTime The RTSJ Clock class defines the abstract class from which all clocks are derived The specification allows many different types of clocks; for example, there could be a CPU execution-time clock (although this is not required by the RTSJ) There is always one real-time clock which advances monotonically ◦ A static method getRealtimeClock allows this clock to be obtained 15
- 16. Clocks andTime Clocks andTime Not the rigth solution for real-time – absolute time! This approach would only measure the approximate elapse time, as the schedulable object executing the code may be pre-empted after it has finished the computation and before it reads the new time 16 { AbsoluteTime oldTime, newTime; RelativeTime interval; Clock clock = Clock.getRealtimeClock(); oldTime = clock.getTime(); // other computations newTime = clock.getTime(); interval = newTime.subtract(oldTime); }
- 17. Scheduling Scheduling Java offers no guarantees that the highest priority runnable thread will always be the one executing This is because a JVM may be relying on a host operating system to support its threads; some of these systems may not support pre- emptive priority-based scheduling Java only defines 10 priority levels and an implementation is free to map these priorities onto a more restricted host operating system’s priority range if necessary The weak definition of scheduling and the restricted range of priorities means that Java programs lacks predictability and, hence, Java’s use for real-time systems implementation is severely limited 17
- 18. Schedulable Objects Schedulable Objects RTSJ generalizes the entities that can be scheduled from threads to the notion of schedulable objects A schedulable object is one which implements the Schedulable interface ◦ Real-time threads and asynchronous event handlers implement this interface Each schedulable object must also indicate its specific ◦ release requirement (that is, when it should become runnable), ◦ memory requirements (for example, the rate at which the object will allocate memory on the heap) ◦ scheduling requirements (for example, the priority at which it should be scheduled) 18
- 19. Schedulable interface Schedulable interface 19 public interface Schedulable extends Runnable { // ... public boolean setIfFeasible( ReleaseParameters release, MemoryParameters memory); public boolean setReleaseParametersIfFeasible( ReleaseParameters release); public void setMemoryParameters(MemoryParameters memory); public void setReleaseParameters(ReleaseParameters release); // ... public SchedulingParameters getSchedulingParameters(); public void setSchedulingParameters( SchedulingParameters sched); public Scheduler getScheduler(); public void setScheduler(Scheduler scheduler); public void setScheduler(Scheduler scheduler, SchedulingParameters scheduling, ReleaseParameters release, MemoryParameters memory, ProcessingGroupParameters processing);
- 20. The Priority Scheduler The Priority Scheduler RTSJ defines the priority scheduler ◦ Scheduler is an abstract class with PriorityScheduler a defined subclass ◦ This allows an implementation to provide, say, an Earliest-Deadline-First scheduler Scheduling 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 to be changed by the programmer at run time ◦ Supports priority inheritance or priority ceiling emulation inheritance for synchronized objects (covered later) 20
- 21. The Priority Scheduler The Priority Scheduler Scheduling mechanism: ◦ The processor resource is always given to the highest priority runnable schedulable object. ◦ places a blocked schedulable object that becomes runnable, or has its base priority changed, at the back of the run queue associated with its (new) active priority. ◦ places a schedulable object that performs Thread.yield method call at the back of the run queue associated with its priority. ◦ does not define whether schedulable objects of the same priority are scheduled in FIFO, round-robin or any other order. ◦ Does not require that feasibility analysis is supported. 21
- 22. Scheduling Parameters Scheduling Parameters Scheduling parameters are used by a scheduler to determine which object is currently the most eligible for execution The abstract class SchedulingParameters provides the root class from which a range of possible scheduling criteria can be expressed The RTSJ defines only one criterion which is based on priority High numerical values for priority represent high execution eligibilities. ImportanceParameters allow an additional numerical scheduling metric to be assigned; it is a subclass of the PriorityParameters 22
- 23. Real-Time Thread Real-Time Thread For real-time systems, it is necessary to model the activities in the controlled system with concurrent entities in the program Standard Java supports the notion of a thread, however, in practice Java threads are both too general and yet not expressive enough to capture the properties of real-time activities E.g., most activities have deadlines yet there are no notion of deadlines in standard Java Real-time activities are also usually characterized by their execution patterns: being periodic, sporadic or aperiodic; representing these in standard Java can only be done by coding conventions in the program Such conventions are error prone and obscure the true nature of the application RTSJ has a good support for periodic threads but, it lacks support for aperiodic and sporadic threads. ◦ WaitForNextPeriod 23
- 24. Real-Time Threads Real-Time Threads A schedulable object (more than an extension of java.lang.thread) No heap version ensure no access to the heap and therefore independence from garbage collection ◦ The RTSJ defines two classes: RealtimeThread and NoHeapRealtimeThread Real-time threads are schedulable objects and, therefore, can have associated release, scheduling, and memory parameters. A real-time thread can also have its memory area set By default, a real-time thread inherits the parameters of its parent (that is the thread that created it). If the parent has no scheduling parameters (perhaps because it was a standard Java thread), the scheduler’s default value is used. For the priority scheduler, this is the normal priority. 24
- 25. Real-Time Threads Real-Time Threads 25 public class Periodic extends RealtimeThread { public Periodic( PriorityParameters PP, PeriodicParameters P) { super(pp, p); }; public void run() { boolean noProblems = true; while(noProblems) { // code to be run each period ... noProblems = waitForNextPeriod(); } // a deadline has been missed, // and there is no handler ... } }
- 26. Real-Time Threads Real-Time Threads 26 public class PriorityParameters extends SchedulingParameters { public PriorityParameters(int priority); // other methods public int getPriority(); } public class PeriodicParameters extends ReleaseParameters { public PeriodicParameters(HighResolutionTime start, RelativeTime period); // other methods } Use in previous code: PriorityParameters PP = new PriorityParameters(11); PeriodicParameters P = new PeriodicParameters ( new RelativeTime(500,0)); // 0.5 sec Periodic pThread1 = new Periodic(PP, P);
- 27. No Heap Real-Time Threads No Heap Real-Time Threads One of the main weaknesses with standard Java, from a real-time perspective, is that threads can be arbitrarily delayed by the action of the garbage collector The RTSJ has attacked this problem by allowing objects to be created in memory areas other than the heap ◦ These areas are not subject to garbage collection A no-heap real-time thread is a real-time thread which only ever accesses non-heap memory areas Consequently, it can safely be executed even when the garbage collection is occurring 27
- 28. No Heap Real-Time Threads No Heap Real-Time Threads The constructors for the NoHeapRealtimeThread class all contain references to a memory area; all memory allocation performed by the thread will be from within this memory area An unchecked exception is thrown if the HeapMemory area is passed The start method is redefined; its goal is to check that the NoHeapRealtimeThread has not been allocated on the heap and that it has obtained no heap-allocated parameters If either of these requirements have been violated, an unchecked exception is thrown 28
- 29. Asynchronous Event Handling Asynchronous Event Handling Threads and real-time threads are the appropriate abstractions to use to represent concurrent activities that have a significant life history It is also necessary to respond to events that happen asynchronously to a thread’s activity These events may be happenings in the environment of an embedded system or notifications received from internal activities within the program It is always possible to have extra threads which wait for these events but this is inefficient From a real-time perspective, events may require their handlers to respond within a deadline; hence, more control is needed over the order in which events are handled 29
- 30. Asynchronous Event Handling Asynchronous Event Handling The RTSJ generalizes Java event handlers to be schedulable entities Each event has an associated handler; when events occur, they are queued and one or more server thread takes an event from the queue and executes it associated handler When the handler has finished, the server takes another event from the queue, executes the handler and so on There is no need for explicit communication between the handlers. 30
- 31. Asynchronous Event Handling Asynchronous Event Handling The RTSJ approach: ◦ Attempt to provide the flexibility of threads and the efficiency of event handling via the notion of real-time asynchronous events (AE) and associated handlers (AEH) ◦ AEs are data-less happenings which are either fired by the program or associated with the occurrence of interrupts in the environment ◦ One or more AEH can be associated with a single event, and a single AEH can be associated with one or more events ◦ The run method of the AsyncEventHandler class itself is the method that will be called by the underlying system when the object is first released ◦ It will call handleAsyncEvent repeatedly whenever the fire count is greater than zero 31
- 32. Asynchronous Event Handling Asynchronous Event Handling 32 package javax.realtime; public class AsyncEventHandler implements Schedulable { //constructors public AsyncEventHandler(); public AsyncEventHandler(java.lang.Runnable logic); public AsyncEventHandler(boolean nonheap); public AsyncEventHandler(boolean nonheap, java.lang.Runnable logic); public AsyncEventHandler( SchedulingParameters scheduling, ReleaseParameters release, MemoryParameters memory, MemoryArea area, ProcessingGroupParameters group); ... // various other combinations and methods public void handleAsyncEvent(); public final void run(); }
- 33. Timers Timers The abstract Timer class defines the base class from which timer events can be generated ◦ All timers are based on a clock; a null clock values indicates that the RealtimeClock should be used ◦ A timer has a time at which it should fire; that is release its associated handlers ◦ This time may be an absolute or relative time value ◦ If no handlers have been associated with the timer, nothing will happen when the timer fires ◦ Once created a timer can be explicitly destroyed, disabled (which allows the timer to continue counting down but prevents it from firing) and enabled (after it has been disabled) ◦ If a timer is enabled after its firing time has passed, the firing is lost ◦ The reschedule method allows the firing time to be changed ◦ Finally the start method, starts the timer going ◦ Any relative time given in the constructor is converted to an absolute time at this point; if an absolute time was given in the constructor, and the time has passed, the timer fires immediately 33
- 34. Timers Timers 34 package javax.realtime; public abstract class Timer extends AsyncEvent { // constructors protected Timer(HighResolutionTime time, Clock clock, AsyncEventHandler handler); // methods public ReleaseParameters createReleaseParameters(); public void destroy(); public void disable(); public void enable(); public Clock getClock(); public AbsoluteTime getFireTime(); public void reschedule(HighResolutionTime time); public void start(); public boolean stop(); }
- 35. Timers Timers 35 package javax.realtime; public class OneShotTimer extends Timer { // constructors public OneShotTimer(HighResolutionTime fireTime, AsyncEventHandler handler); // assumes the default real-time clock public OneShotTimer(HighResolutionTime fireTime, Clock clock, AsyncEventHandler handler); // fireTime is based on the clock parameter }
- 36. Timers Timers 36 package javax.realtime; public class PeriodicTimer extends Timer { // constructors public PeriodicTimer(HighResolutionTime start, RelativeTime interval AsyncEventHandler handler); // assumes the default real-time clock // ... }
- 37. Asynchronous Transfer of Control Asynchronous Transfer of Control Asynchronous events allow the program to respond in a timely fashion to a condition that has been detected by the program or the environment They do not allow a particular schedulable object to be directly informed In many applications, the only form of asynchronous transfer of control that a thread needs is a request for it to terminate itself ◦ Consequently, languages and operating systems typically provide a kill or abort facility For real-time systems, this approach an alternative is needed; it is required for the schedulable object to stop what it is currently doing and to begin executing an alternative algorithm 37
- 38. Asynchronous Transfer of Control Asynchronous Transfer of Control In standard Java, it is the interrupt mechanism which attempts to provide a form of asynchronous transfer of control The mechanism does not support timely response to the “interrupt” ◦ Instead, a running thread has to poll for notification This delay is deemed unacceptable for real-time systems ◦ For these reasons, the RTSJ provides an alternative approach for interrupting a schedulable object, using asynchronous transfer of control (ATC) 38
- 39. Asynchronous Transfer of Control Asynchronous Transfer of Control The ATC model is based on the following principles ◦ A schedulable object must explicitly indicate that it is prepared to allow an ATC to be delivered ◦ By default, schedulable object will have ATCs deferred ◦ The execution of synchronized methods and statements always defers the delivery of an ATC 39
- 40. Asynchronous Transfer of Control Asynchronous Transfer of Control The RTSJ ATC model is integrated with the Java exception handling facility ◦ An AsynchronouslyInterruptedException (AIE) class defines the ATC event ◦ A method that is prepared to allow an AIE indicate so via a throws AsynchronouslyInterruptedException in its declaration ◦ The executing thread must implement the Interruptible interface 40
- 41. Mode Manager Mode Manager 41 import javax.realtime.*; public class ModeA implements Interruptible { public void run(AsynchronouslyInterruptedException aie) throws AsynchronouslyInterruptedException { // operation performed in Mode A } public void interruptAction( AsynchronouslyInterruptedException aie) { // reset any internal state, so that when Mode A // becomes current, it can continue } } // similary for ModeB
- 42. Mode Manager Mode Manager 42 import javax.realtime.*; public class ModeChanger extends AsynchronouslyInterruptedException { public static final int MODE_A = 0; public static final int MODE_B = 1; public ModeChanger(int initial) { super(); if(initial == MODE_A) current = MODE_A; else if(initial == MODE_B) current = MODE_B; else throw new IllegalArgumentException(); } public synchronized void setMode(int nextMode) { if(nextMode == MODE_A | nextMode == MODE_B) current = nextMode; else throw new IllegalArgumentException(); } public synchronized void toggleMode() { if(current == MODE_A) current = MODE_B; else current = MODE_A; } private int current; }
- 43. Mode Manager Mode Manager 43 ModeChanger modeChange = newModeChanger( ModeChanger.MODE_A) ; public void run() // inside a RT thread with // PeriodicParameters { ModeA modeA = new ModeA(); ModeB modeB = new ModeB(); boolean ok = true; boolean result; while(ok) { if(modeChange.currentMode() == ModeChanger.MODE_A) result = modeChange.doInterruptible(modeA); //throw away result else result = modeChange.doInterruptible(modeB); //throw away result ok = waitForNextPeriod(); } } signaller: modeChange.toggleMode(); modeChange.fire();
- 44. Asynchronous Transfer of Control Asynchronous Transfer of Control Although AIEs appear to have been integrated into the Java exception handling mechanism, the normal Java rules to not apply ◦ Only the naming of the AIE class in a throw clause indicates the thread is interruptible. ◦ Handlers for AIEs do not automatically stop the propagation of the AIE. It is necessary to call the clear method in the AIE class ◦ Although catch clauses in ATC-deferred regions that name the InterruptedException or Exception classes will handle an AIE this will not stop the propagation of the AIE ◦ Although AIE is a subclass of InterruptedException which is a subclass of Exception, catch clauses which name these classes in AI-methods will not catch an AIE ◦ Finally clauses that are declared in AI-methods are not executed when an ATC is thrown ◦ Where a synchronous exception is propagating into an AI-method, and there is a pending AIE, the synchronous exception is lost when the AIE is thrown 44
- 45. Synchronization Synchronization Java provides mutually exclusive access to shared data via a monitor-like construct All synchronization mechanisms which are based on mutual exclusion suffer from priority inversion The problem of priority inversion and its solution (priority inheritance) is now a well-researched area of real-time systems There are a variety of priority inheritance algorithms; the RTSJ explicitly support two: simple priority inheritance and priority ceiling emulation inheritance (sometimes called immediate ceiling priority inheritance or priority protect inheritance protocol) 45
- 46. Priority Inversion control Priority Inversion control In order to limit the length of blocking time, the RTSJ requires the following: ◦ All queues maintained by the system to be priority ordered (e.g. the queue of schedulable objects waiting for an object lock ◦ Where there is more than one schedulable object in the queue at the same priority, the order should be first-in-first-out (FIFO) ◦ Similarly, the queues resulting from calling the wait method in the Object class should be priority ordered By default, the RTSJ requires simple priority inheritance to occur whenever a schedulable object is blocked waiting for a resource Available facilities for the programmer to specify different priority inversion control algorithms 46
- 47. Priority Inversion control Priority Inversion control 47 public abstract class MonitorControl { public static void setMonitorControl( MonitorControl policy); public static void setMonitorControl( Object monitor, MonitorControl policy); } public class PriorityInheritance extends MonitorControl { // methods public static PriorityInheritance instance(); } public class PriorityCeilingEmulation extends MonitorControl { public static PriorityCeilingEmulation instance(int ceiling); public int getCeiling(); ... }
- 48. Priority Inversion Control Priority Inversion Control Most large real-time systems will consists of a mixture of heap- using and no-heap schedulable objects There will be occasions when they need to exchange information To ensure that no-heap schedulable objects are not indirectly delayed by garbage collection requires ◦ all no-heap schedulable object should have priorities greater than heap-using schedulable objects, ◦ priority ceiling emulation should be used for all shared synchronized objects, ◦ all shared synchronized object should have their memory requirements pre- allocated (or dynamically allocated from scoped or immortal memory areas), and ◦ objects passed in any communication should be primitive types passed by value (int, long, boolean etc) or be from scoped or immortal memory If these conditions are fulfilled, then there will be no unwanted interference from the garbage collector at inopportune moments 48
- 49. Priority Inheritance and Garbage Priority Inheritance and Garbage Collection Collection If real-time threads want to communicate with non real-time threads then interaction with garbage collection must be considered It is necessary to try to avoid the situation where a non real-time thread has entered into a mutual exclusion zone shared with a real-time thread If priority inheritance is used and shared objects are preallocated on the heap, do you see any problem? 49
- 50. Priority Inheritance and Garbage Priority Inheritance and Garbage Collection Collection Yes, there is: ◦ A Java thread,T1, enters into the monitor first (the schedulable object is currently not released), ◦ it is then preempted by a higher-priority Java thread,T2, whose operations cause garbage collection to occur, ◦ at this point, the schedulable object is released, preempts the garbage collector but cannot access the monitor ◦ priority inheritance occurs, but it is not safe for the Java thread, T1, to execute as memory compaction may be taking place. With priority ceiling emulation, the above scenario cannot occur, as T1 will inherit a priority higher than all Java threads the moment it enters into the monitor. Hence, it cannot be preempted by T2. 50
- 51. Wait Free Communication Wait Free Communication One way of avoiding unpredictable interactions with the garbage collector is to provide a non-blocking communication mechanism for use between non real- time threads and real-time threads The RTSJ provides three/two wait-free non blocking classes to help facilitate this communication: ◦ WaitFreeWriteQueue: this class is intended for situations where a no-heap real-time thread wishes to send data to one or more heap-using threads. However, it can be used by any thread. Essentially, the writer thread is never blocked when writing even when the queue is full (the write fails). Readers can be blocked hen the queue is empty.The class assumes that multiple writers provide their own synchronization. 51
- 52. Wait Free Communication Wait Free Communication ◦ WaitFreeReadQueue: this class is intended for situations where a no-heap real-time thread wishes to receive data from one or more heap-using threads. However, it can be used by any thread. Essentially, the reader thread is never blocked when reading even when the queue is empty (the read fails).Writers can be blocked when the queue is full.The class assumes that multiple readers provide their own synchronization. ◦ WaitFreeDequeue: mix of the other two. Deprecated. 52
- 53. Conclusion Conclusion Java has been generally successful, however not yet in the real-time and embedded markets ◦ The provision of real-time programming abstractions along with the promise of a predictable real-time JavaVirtual Machine has the potential give Java a foothold However, there are still obstacles to be overcome: ◦ Specification — to produce a consistent and unambiguous Real-Time Specification for Java along with well-defined profiles for particular real-time application domains ◦ Implementation — to generate efficient implementations of real-time virtual machines (both open source and propriety ones) for the full specification and the profiles ◦ Maintaining Momentum — to stimulate evolution of the specification in a controlled and sustained manner to add new functionality and to address new architectures 53
- 54. Conclusion Conclusion With any new technology, there is a tension between producing a stable standard base which users can depend on, and providing a dynamic product that continues to evolve and address new application needs Java has caught the imagination of the user-community, produced stable releases and maintained momentum for its evolution. If the RTSJ is to survive, it is important that it keeps pace with the more general Java development and also that it develops its own momentum. ◦ New standard schedulers ◦ Multiple schedulers ◦ Multiple criticalities ◦ Alternative interrupt handling models ◦ Real-time concurrency utilities ◦ Multiprocessor and distributed systems 54