Real Time Systems Communication Services. Communication (part 1) - 2 Outline Asynchronous...
-
Upload
constance-eustacia-davidson -
Category
Documents
-
view
218 -
download
0
Transcript of Real Time Systems Communication Services. Communication (part 1) - 2 Outline Asynchronous...
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