CS452 - Real-Time Programming - Fall 2011

Lecture 9 - Send/Receive/Reply

Public Service Annoucements

1. Reference handin for a0.

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.

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

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. Here is some XXX
   • Warehouse blocks sender, saves XXX, or provides XXX
2. I want some XXX
   • Warehouse blocks sender, provides XXX,, or queues sender

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 was called first AND
     • the Receiver's SendQ is 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
   • Whwn 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.

Practical Details

• Need to keep around request
  • For Send_Blocked receivers in the SendQ
  • Where is it kept?
• Messages
  • Typed as strings
    • which require formatting and parsing
  • Normally cast from char* to struct*
    • probably should be void*
    • sizeof( ) is useful
    • struct expected by receiver/sender must agree with struct provided by sender/receiver
    • Type-checking by compiler not possible
    • Dynamic type-checking possible
      • First element of struct is its type
      • Even polymorphism is possible
• Message types could be handled in a more modern way
  • type extension
  • would provide a more uniform handling of error returns
• Task states
  1. DEFUNCT is terminal
  2. READY -> ACTIVE
  3. ACTIVE -> SEND_BLOCKED, RECEIVE_BLOCKED, READY, DEFUNCT
  4. SEND_BLOCKED -> READY
  5. RECEIVE_BLOCKED -> REPLY_BLOCKED
  6. REPLY_BLOCKED -> READY
• You can add extra return values beyond those specified

Note. You may find the descriptions below overly elaborate, but they catch the obvious corner cases.

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

These are pretty self explanatory, except

1. The return value is the number of characters actually placed in the reply-buffer
   • including the terminal character ( \000 ) if the contents of the reply buffer is a string
2. If something goes wrong, the return value is negative, coded to indicate what went wrong

   What can go wrong

   1. Illegal tid
   2. tid not an existing task

   It's up to Send to check that the reply-buffer was big enough by looking at its return value

   It's not an error if the task to which we Send never Receives

   • Should it be?
   • Hint. Finding out if a task "never Receives" is equivalent to what problem?
3. Parsing argument and reply-buffer is potentially costly and error-prone
   • A type system might be nice
   • But then you would feel compelled to implement run-time type checking

Implementing Send

What's in user space is just stubs.

• checking arguments
• putting arguments in the right place
  • Note that there are five arguments. Where does the fifth go?

What the kernel must do

1. Check arguments
   • tid is valid?
2. Change state of sender to RECEIVE_BLOCKED
3. Put sender on the end of the receiver's sendQ
4. If receiver is SEND_BLOCKED, do #5 in Implementing Receive, below.

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

These are pretty self explanatory, except

1. How is the task id copied form kernel to receiver?
   • That is, where does the pointer point to?
2. What if the buffer wasn't big enough?
3. If several tasks have done Send, which one gets Received first?
4. return value is number of bytes in message, including terminal character (\000) if the message is really a string..
   • It seems as though the return value should be the tid. Something is not right.
5. If something goes wrong, the return value is negative, coded to indicate what went wrong

   What can go wrong?

   1. Only part of the message was copied

   It's up to Receive to check that the message-buffer was big enough by looking at its return value

Implementing Receive

What the kernel must do

1. Check arguments
2. Change receiver's state to SEND_BLOCKED
3. Check the sendQ
4. If SENDQ_EMPTY
   1. Exit from kernel after scheduling
5. else
   1. extract head of the send queue, the sender
   2. copy message from sender to receiver, after checking buffer sizes
   3. change sender's state to REPLY_BLOCKED
   4. change receiver's state to READY
   5. put sender's tid into receiver's argument
   6. put receiver on its readyQ
   7. set up receiver's return value

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

These are pretty self explanatory, except

1. The Replyer need not be the Receiver, but must be in contact with the Receiver
   • Why?
2. When all goes well Reply leaves two tasks READY when it completes

Implementing Reply

1. Check arguments
   • sender (tid) must be REPLY_BLOCKED
2. Copy message from replier to sender, checking buffer sizes
3. Put sender on readyQ
4. Set up sender's return value
5. Change sender's state to READY
6. Put replier on readyQ
7. Set up replier's return value
8. Change replier's state to READY.

Return to:

• Bill Cowan's Fall 2011 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page