CS452 - Real-Time Programming - Spring 2013

Send/Receive/Reply

Pubilc Service Annoucements

1. Due date for kernel 2: 31 May.

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 from you."
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.
  • Critical races 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, ack 1 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

• Keeping around the request
  • Send before Receive
    • request is a pointer into the sender's address space
    • sender is still blocked when copying occurs
    • request is copied from sender's address space into receiver's address space by kernel while receive is being handled.
  • Receive before Send
    • request will be copied to a pointer into the receiver's address space
    • receiver remains blocked until send occurs
    • request is copied from sender's address space into receiver's address space by kernel while send is being handled.
  • Reply
    • response is a pointer into the replier's address space
    • sender is still blocked when copying occurs
    • response is copied from replier's address space into sender's address space by kernel while reply is being handled.
• Copying inside the kernel is the reason why you want
  • unformatted messages
  • fast memcpy
• Messages
• Task states
• You can add extra return values beyond those specified

Example of a Difficult Bug

You notice that

• Tasks that are RCV_BL are never on ReadyQs.
• The next pointer is available to link the Receiver's sendQ.

Your reasoning is based on the following scenario.

1. Sender calls Send while receiver is RDY.
2. Sender is placed on receiver's SendQ.
3. A second sender calls Send before first sender has been received.
4. The second sender is put on the first sender's next pointer.
5. As many more as you like.
6. Receiver calls Receive and immediately has a transaction with first sender.
   • removing the first sender from the SendQ pulls the second sender onto it.
7. Receiver calls Reply; both receiver and first sender are RDY.
   • first sender's next pointer is available for use in ReadyQ.
8. Receiver runs first, calls Receive and handles second sender

Return to:

• Bill Cowan's lecture notes for CS452 in s13
• Bill Cowan's Spring 2013 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page