CS452 - Real-Time Programming - Spring 2012

Lecture 9 - Send/Receive/Reply

Pubilc Service Annoucements

1. Due date for assignment 1
2. Next week's classes
3. Assignment 2
   • due date
   • what you do

Inter-task Communication

Overview

Message passing combines synchronization and communication in one set of primitives.

• Send, Receive, Reply

int Send( Tid tid, char *message, int mslen, char *reply, int rplen )

• blocks until Reply occurs

int Receive( Tid *tid, char *message, int mslen )

• blocks until message is available
• Only one waiting sender is processed per Receive
  • Why?
  • Hint. There might be tasks that are higher priority than the Receiver.

int Reply( Tid tid, char *reply, int rplen )

• does not block
• unblocks task that called Send

Send and Reply become READY at the same time.

How are They Used?

The Producer/Consumer Problem

+--------------+          +--------------+
|              |          |              |
|   Producer   |   ===>   |   Consumer   |
|              |          |              |
+--------------+          +--------------+

Producer Sends

1. producer sends and blocks (I have some XXX for you)
2. consumer receives (Give me some XXX)
3. consumer accepts XXX
4. consumer replies (I got the XXX)
5. producer & consumer are simultaneously READY

Note. 1 & 2 could be run in the opposite order

Consumer Sends

1. Consumer sends and blocks (`I am ready for some XXX.')
2. Producer receives (`I have some XXX.')
3. Producer replies (`Here is the XXX')
4. Consumer accepts XXX
5. Producer and consumer are simultaneously READY

Note. 1 & 2 could be run in the opposite order

Multiple Producers

Producers send; consumer receives in the order that producers send.

Notes.

• Critical races can occur, which the application programmer must resolve.
• There are two types of critical race
  • Ones internal to the application. For example, order of production changes in one producer because you add or remove a printf statement. These ones you can program out of existence by changing priorities, communication patterns, etc.
  • Ones external to the application. For example, one producer is forwarding bytes from the keyboard, the other from the train controller, and the order of production changes because the user types a little faster. These ones you cannot program out of existence, but must program so that the right thing happens regardless of the order of production.

Multiple Consumers

Consumers send; producer receives in the order that consumers send.

Note. Critical races can occur, which the application programmer must resolve.

Multiple Consumers AND Multiple Producers

Consumers send and producers send: who receives?

• A third task: you call it a FIFO or buffer; I call it a warehouse

+---------------+          +------------+          +---------------+
|               |          |            |          |               |
|   Producers   |   ===>   |   Buffer   |   ===>   |   Consumers   |
|               |          |            |          |               |
+---------------+          +------------+          +---------------+

Buffer receives two types of request

1. Producer: Here is some XXX

   Send( ..., accept some XXX, ... )

   • Warehouse stores XXX, replies

     Reply( sender, got XXX, )

   • If warehouse is full of XXX two strategies are possible
     1. Warehouse queues sender, who remains Reply_Blocked
     2. Warehouse replies with refusal

        Reply( sender, won't take XXX, )

2. Consumer: I want some YYY

   Send( ..., want some YYY, ... )

   • Warehouse provides YYY, replies

     Reply( sender, here is YYY, )

   • If warehouse is empty of YYY, two strategies are possible
     1. Warehouse queues sender, who remains Reply_Blocked
     2. Warehouse replies with refusal

        Reply( sender, all out of YYY, )

Only a receiver can accept two types of requests at once.

Sequence of States

Sender

1. Active -> Receive_Blocked
   • When Send is called
2. Receive_Blocked -> Reply_Blocked
   • May happen right away
     • When Receive is called with the Receiver's SendQ empty
   • Otherwise, when Receive is called
3. Reply_Blocked -> Ready
   • When Reply is called

Receiver

1. Active -> Send_Blocked
2. Send_Blocked -> Ready
   • May happen right away
     • if the sendQ is not empty
3. Ready -> Active
4. ...
5. Active -> Ready
   • When Reply is called

There are two cases

Send before Receive

Send
           ...
           Receive
           ...
           Reply
...        ...

Message copying occurs inside Receive and Reply.

Receive needs to have a list of current senders, the ReceiveQ

Receive before Send

            Receive
...
Send
            ...
            Reply
...         ...

Message copying occurs inside Send and Reply.

Example of a Difficult Bug

1. You notice that a Receiver is never on a readyQ when it is Send_Blocked
2. You decide to use the next pointer in the TD for the head of the sendQ
   • probably to fit two TDs into a single cache line
3. You test and test and test and nothing ever goes wrong
4. One week before the demo, your kernel crashes under your application
5. What two things might have gone wrong?
   • You might have caught one while testing, not likely the other.

Return to:

• Bill Cowan's lecture notes for CS452 in s12
• Bill Cowan's Spring 2012 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page