Real Time Systems

CommunicationServices

Communication (part 1) - 2

Outline

Asynchronous Communication

Synchronous Communication Uses of Synchronous Communication

Common Problems

Receiving Messages

Timed Invokes

Coordinated Jammer Example

Event Deferral

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

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).

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

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( );

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

Communication (part 1) - 8

Synchronous Communications – timed 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

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

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)

Communication (part 1) - 11

Example – an EW Controller

Communication (part 1) - 12

Controller

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:

Communication (part 1) - 14

Receiver

Asynchronous:{no code}

rxJamPort.ack( ).reply( );//note that arrowhead would be // blackened in this case.

Synchronous:

Communication (part 1) - 15

Synchronous Communication -supplemental issues

Invoke – Reply in the presence of timers Invoke – Reply and “lengthy” replies Invoke – Reply and “delayed” replies

See model file: InvokeTest.rtmdl