1 / 38

Distributed Real-Time in the RTSJ

Distributed Real-Time in the RTSJ. Andrew Borg. Presentation. RMI – A brief introduction The RTSJ – A (very) brief introduction The DRTSJ – The 3 Levels of Integration RMI+RTSJ: Concerns, Issues and Solutions. Presentation. RMI – A brief introduction The RTSJ – A brief introduction

piper
Download Presentation

Distributed Real-Time in the RTSJ

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Distributed Real-Time in the RTSJ Andrew Borg

  2. Presentation • RMI – A brief introduction • The RTSJ – A (very) brief introduction • The DRTSJ – The 3 Levels of Integration • RMI+RTSJ: Concerns, Issues and Solutions

  3. Presentation • RMI – A brief introduction • The RTSJ – A brief introduction • The DRTSJ – Current Status • RMI+RTSJ: Concerns, Issues and Solutions

  4. The RMI Specification • RMI is very minimal. • Assumes a homogeneous environment of JVMs. • There is no ORB concept (see later)

  5. Goals • Support seamless remote invocation on objects. • Retain most of the Java language's object semantics. • Make differences between the distributed object model and local Java object model apparent. • Make writing reliable distributed applications as simple as possible. • Preserve the type-safety provided by the Java runtime environment. • Various reference semantics for remote objects; for example live (nonpersistent) references, persistent references, and lazy activation. • Enforce the safe Java environment provided by security managers and class loaders.

  6. A simple HelloPerson example • Client sends name to a server. • Server returns “hello ” +the name passed

  7. The interface public interface HelloPersonInterface extends java.rmi.Remote { public void sayHello() throws java.rmi.RemoteException; }

  8. The Implementation public class HelloPerson implements HelloPersonInterface { public HelloPerson () {} public String sayHello(String S) { return new String("Hello World"+S); } }

  9. Generate Stub Using rmic • … See later

  10. Launching the Server { Registry r= createRegistry(4321); HelloPersonImpl x = new HelloPersonImpl(); Remote s = UnicastRemoteObject.exportObject(x); r.bind("MyHelloServer",s); }

  11. Invoking the Server HelloServerInterface H = (HelloServerInterface) r.lookup("MyHelloServer"); System.out.println(H.sayHello("Andrew"));

  12. The RMI Classes Interface ServerStub Server

  13. The Stub public final class HelloServerImpl_Stub extends java.rmi.server.RemoteStub implements HelloServerInterface { public java.lang.String sayHello(java.lang.String $param_String_1) throws java.rmi.RemoteException { Object $result = ref.invoke(this, $method_sayHello_0, new java.lang.Object[] {$param_String_1}, 8370655165776887524L); return ((java.lang.String) $result); }

  14. Distributed vs. Centralised • Clients of remote objects interact with remote interfaces • Non-remote arguments to, and results from, an RMI call are passed by copy. • A remote object is passed by reference, not by copying the actual remote implementation. • Since the failure modes of invoking remote objects are inherently more complicated than the failure modes of invoking local objects, clients must deal with additional exceptions.

  15. The DGC • Is part of the specification • Uses a lease-mechanism with reference counting • Internally also keeps the VM alive when remote objects exist

  16. JRMP • Serialization Protocol • HTTP Protocol • Output defines sub-protocol: • single-op • stream • multiplex

  17. Presentation • RMI – A brief introduction • The RTSJ – A brief introduction • The DRTSJ – The 3 Levels of Integration • RMI+RTSJ: Concerns, Issues and Solutions

  18. The Real Time Specification for Java (RTSJ) • The 7 enhanced areas over Java: • Thread Scheduling and Dispatching • Memory Management • Synchronization and Resource Sharing • Asynchronous Event Handling • Asynchronous Transfer of Control • Asynchronous Thread Termination • Physical Memory Access

  19. JSR 50 • … extends RMI in the RTSJ to provide support for predictability of end-to-end timeliness of trans-node activities. • Expert group has published a framework for the implementation of JSR 50, describing three levels of integration.

  20. The 3 levels of Integration • Level 0: RTSJ + RMI • Level 1: RTSJ + Realtime RMI • Level 2: RTSJ + Realtime RMI + Distributed Threads

  21. Two Requirements for RT-RMI • Requirement 1: Real-time Invocation • End-to-End timeliness in the invocation process • Requirement 2: Support for RT-RMI • Serialization, the DGC, etc.

  22. Real-time Invocation Control in RT-RMI RMI in Java RT-RMI

  23. The RMI Classes

  24. Exporting Server Parameters • Export methods defined in subclass of RealtimeRemoteServer: public static RealtimeRemoteServer exportObject ( RealtimeRemote obj, int port, SchedulingParameters sp, NetworkParams np, Threadpool pool ) • Realtime-parameters passed up to RealtimeRemoteServer • Network parameters stay with subclass

  25. Propagating Client Parameters • Assigning parameters to a RealtimeRemoteStub instance. • Implicitly inheriting or deriving the parameters from the client Schedulable object. • Explicitly specifying parameters for each invocation.

  26. RT-RMI Server Thread Model Single Acceptor Thread associate with each exported object Acceptor is most eligible thread if CP Accepts call and deserialises RT parameters Handler Thread Deserialises non RT parameters Makes Upcall on Object Serialises the result and sends back to the server Threadpool of handler Threads

  27. Memory Considerations in implementation • Problems for the application developer: • Parameters exported are used in the Schedulables created. • RTSJ scoping rules must be respected in the upcall • Problems for the developer: • Threadpools implementation in not trivial • Proper scoping should be used to free objects after invocation

  28. The DGC • If scoped memory removes GC, can it also be used to solve DGC? • What are the semantics involved? • In particular, what is a remote object?

  29. Connections • Should be part of a spec? • Attach connections to pools? • Can we assume connection-oriented protocols • RSVP

  30. Carrying out distribution • How would a correct RTSJ be moved to a distributed environment?

  31. Asynchronicity • What are the semantics of AIEs across node boundaries? • 2 levels to address

  32. CORBA and DRTSJ • Is RTSJ + RTCORBA = DRTSJ? • Must RTCORBA be Java aware? • How would a mapping work?

  33. Conclusion

More Related