1. Real Time Systems Communication Services

2. Communication (part 1) - 2 Outline  Asynchronous Communication  Synchronous Communication  Uses of Synchronous Communication  Common Problems  Receiving Messages  Timed Invokes  Coordinated Jammer Example  Event Deferral

3. Communication (part 1) - 3 Asynchronous Communications  the sending capsule will not “block” while the message is in transit  it will complete all of its transition chain code prior to the sent message(s) even having a chance to be processed  other messages, and other transition chains, may even be processed in the interim  mechanics:  myPort.mySignal( [data] ).send( [priority] );  see Services Library class OutSignal optional

4. Communication (part 1) - 4 Asynchronous Communications  recall run-to-completion semantics:  when fired, each transition chain will “naturally” run-to-completion.  any messages sent during any code of the transition chain will be queued by the message handling services of the RT Service Library  equal priority messages will be processed FIFO  other messages already in the queue (behind the one which started the original transition) will be processed before the new sent message(s).

5. Communication (part 1) - 5 Synchronous Communications  provides a means of circumventing normal run-to-completion semantics  the sending (invoking) capsule blocks until a reply is received (procedure call semantics)  the block is effective even against higher priority messages being received  nested synchronous communication is permitted, but not circular

6. Communication (part 1) - 6 Synchronous Communications - mechanics  OutSignal.invoke( )  //sender  Message[] replies = senderPort.senderSignal().invoke();  if (replies[0] != null)  { code to handle valid reply }  else  { code to handle invalid reply }  //receiver  receiverPort.receiverSignal( ).reply( );

7. Communication (part 1) - 7 Synchronous Communications – receiver decoupling  RoseRT’s event-driven behavior ensures that states are always in “receive-mode”  messages received are treated the same (on the receiving end) regardless of whether they were sent asynchronously or synchronously  de-couples receiver / sender implementation  however, for this assurance to be used, the receiver must send a reply in all cases

8. Communication (part 1) - 8 Synchronous Communications – t imed invokes  timeliness of send capsule (or its thread) may require that an invoke only block for a minimum period of time  receiver may be too slow in responding  communication delays may be too long  communications may be lost  therefore an invoke may require a time-out  optional  no implementation mechanism in RoseRT  only returns an exception if no reply is received

9. Communication (part 1) - 9 Synchronous Communication - why use it?  to control the sequencing of events (state changes)  example: our Receiver/Jammer coordination  to ensure synchronization  example: widget painting system  to ensure non-interference across logical threads or processes (mutual exclusion)  example: a shared database  does NOT work across physical threads

10. Communication (part 1) - 10 Synchronization Communication - pitfalls  can lead to deadlock (circular invokes)  timeliness on thread of sending capsule may be jeopardized  multi-processor communication problems  long delays  reliability (lossy communications)

11. Communication (part 1) - 11 Example – an EW Controller

12. Communication (part 1) - 12 Controller

13. Communication (part 1) - 13 Jammer rxJamPort.Jamming().send(); // some code to actually transmit // RF energy Asynchronous: rxJamPort.Jamming().invoke(); if (replies[0] != null) { // some code to actually // transmit RF energy } else { // abort jamming} Synchronous:

14. Communication (part 1) - 14 Receiver Asynchronous: {no code} rxJamPort.ack( ).reply( ); //note that arrowhead would be // blackened in this case. Synchronous:

15. Communication (part 1) - 15 Synchronous Communication - s upplemental issues  Invoke – Reply in the presence of timers  Invoke – Reply and “lengthy” replies  Invoke – Reply and “delayed” replies  See model file: InvokeTest.rtmdl

16. Communication (part 1) - 16 Model: “InvokeReplywithTimers” InvokeReplywithTimers - Capsules