CS452 - Real-Time Programming - Winter 2013

Lecture 9 - Send/Receive/Reply

Pubilc Service Annoucements

1. Due date for assignment 2

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 *msg, int msglen )

• 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 *rply, int rplylen )

• 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

Middle (double) arrow shows the direction that information flows.

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

Producer Sends

Upper arrow

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

Lower arrow

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( warehouse, accept some XXX, ... )

   • Warehouse receives

     Receive( *producer, XXX )

   • Warehouse stores XXX, replies

     insert( XXX, shelf );
     Reply( producer, got XXX, )

   • If warehouse is full of XXX two strategies are possible
     1. Warehouse queues producer, who remains Reply_Blocked until there is space created in the warehouse
     2. Warehouse replies with refusal

        Reply( producer, can't take XXX, )

        The second strategy is considered to be not so good. Why?

2. Consumer: I want some YYY

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

   • Warehouse receives, gets YYY

     Receive( &consumer, YYY )

   • Warehouse replies, providing YYY

     extract( YYY, shelf);
     Reply( consumer, 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( consumer, all out of YYY, )

Notes.

• Only a receiver can accept two types of requests at once. The buffer, which only receives is the simplest example of a server.
• Messages in Send/Receive/Reply must be the same 'type'.

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

Receive before Send

Practical Details

• Need to keep around request
  • For Send_Blocked receivers in the SendQ
    • The same as Receive_Blocked senders
  • For Reply_Blocked senders.
• Messages
• Task states
• You can add extra return values beyond those specified

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

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 w12
• Bill Cowan's Spring 2012 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page