Real Time Systems

1
Real Time Systems

• Communication
• Services

2
Review
3
Outline

• Asynchronous Communication
• Synchronous Communication
• Uses of Synchronous Communication
• Common Problems
• Receiving Messages
• Timed Invokes
• Coordinated Jammer Example
• Event Deferral

4
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 RTOutSignal

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

6
Synchronous Communications -defined

• 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

7
Synchronous Communications -mechanics

• RTOutSignalinvoke( )
• //sender
• RTMessage replyMessage
• senderPort.senderSignal( ).invoke(replyMessage)
• if (replyMessage.isValid( ))
• code to handle valid reply
• else
• code to handle invalid reply
• //receiver
• receiverPort.receiverSignal( ).reply( )

8
Synchronous Communications receiver decoupling

• RoseRTs 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

9
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

10
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

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

12
Example an EW Controller
13
Controller
14
Jammer
15
Receiver
16
Synchronous Communication -supplemental issues

• Invoke Reply in the presence of timers
• Invoke Reply and lengthy replies
• Invoke Reply and delayed replies
• See model file InvokeReplywithTimers

17
Model InvokeReplywithTimers InvokeReplywithTime
rs - Capsules
18
InvokeReplywithTimers As State
19
InvokeReplywithTimers Bs StateCase
lengthyReply
20
InvokeReplywithTimers Bs StateCase
lengthyReply
21
InvokeReplywithTimers Bs StateCase
delayedReply
22
InvokeReplywithTimers Bs StateCase
delayedReply
23
Event Deferral defined

• real time systems are by default highly reactive
• messages can (and will) arrive at anytime
• perhaps you dont want or cant deal with them at
  this time (youre in the middle of a sequence)
• not all messages necessarily need to be processed
  right away
• design dependent
• a mechanism is required for deferring ,
  recalling and purging messages

24
Event Deferral mechanics

• RTMessagedefer()
• in the transition code of the receiving state
  machine
• msg-gtdefer( )
• //this will queue the message (FIFO) at the
  received port
• RTProtocol RTInSignal recall(), purge()
• in the transition code where it is determined
  that the message can now be handled
• myPort.recall( frontFlag ) or
  myPort.mySignal( ).recall( )
• // this will recall the first deferred message on
  either the port or the type signal, and if
  frontFlag evaluates to TRUE, it will place it at
  the front of its message queue
• returns the number of recalled messages (0 or 1)
  

25
Event Deferral mechanics (continued)

• it must also be possible to clean up any
  deferred messages that may no longer be required
  / valid
• myPort.purge( ) or myPort.mySignal( ).purge( )
• //deletes messages or specific message from the
  queue
• // returns the number of deleted messages from
  the defer queue.

26
Event Deferral Example 1 - A Busy Robot
If another pick-up request comes in
When delivery has been completed
27
Example 2 - A Database Server
28
Example 2 - A Database ServerTheSystem Structure
Diagram
Unwired, synchronous communication between
multiple clients and the database system
29
Example 2 - A Database ServerDatabaseSystem
Structure Diagram
Wired, asynchronous communication
between QueryServer and the Database Note the
relay port(s) for client requests
30
Example 2 - A Database ServerQueryServer State
Diagram
31
Questions