CS452 - Real-Time Programming - Spring 2008

Lecture 14 - Inter-task Communication

Questions & Comment

1. Getting an NMI interrupt (82801EB, ICH5) (I/O Controller Hub)
2. How much memory does the Eos actually have?

Message Passing

Let's think about objects

1. Send a message to an object, asking it to run some code for us, and return an response

We normally think about this in a single threaded way, like a procedure call

1. Call a method and block
2. Method is just sitting, waiting for the call and immediately starts to execute
3. When it's finished executing ut returns a result.
4. We are no longer blocked and continue executing.
5. The method goes back to sitting, waiting

In an environment with multiple threads of control

1. Several threads might call the same method
   • or different methods within the same object

   at the same time.

2. Then the object needs to be `thread-safe'
   • aware that there may be simultaneous execution
   • use monitors, or whatever
3. The object worries about the details
   • but this makes the object very difficult to create, OR
   • if the object isn't thread-safe makes user code very difficult to write

To make the last easier we make the communnication more explicit than it is in a method call

1. To call the method a task calls Send with an argument that indicates which code is to be executed and its environment
2. To indicate its readiness to execute the object calls Receive, which returns which code is to be executed and its environment
3. To indicate that the code has completed its execution the object calls Reply with an argument that indicates the result of the execution
4. Send returns within the task, with the result of the execution

Synchronization details

1. Send blocks the caller
   • Either it has to block sometime
   • Or it needs to poll
   • Or it needs to split into multiple threads

   Most of the time it needs the result before it can proceed further

2. Receive blocks the callee
   • Which makes it easy for the object to control how many executions it is performing
   • And obviates the need for multiple threads
3. Reply blocks nobody
   • The transaction is complete

What practical things can be going on in the sender?

1. Getting some information that's needed
2. Making a request for a service
   • Output some characters
   • Create a new task
3. Waiting for something
   • Input to be available
   • a particular time
   • a resource to be free

int Send( Tid tid, char *arg, int arg-length, char *reply-buffer, int reply-buffer-size )

These are pretty self explanatory, except

1. The return value is the number of characters actually returned
   • including the \0 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
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
4. This form of message passing requires user and kernel code to cooperate to avoid malignancies
   • which is just barely okay when one implementer does both
   • but is otherwise monumentally insecure

int Receive( Tid *tid, char *arg-buffer, int arg-buffer-length )

These are pretty self explanatory, except

int Reply( Tid tid, char *reply, int reply-length )

These are pretty self explanatory, except

Return to:

• Bill Cowan's Winter 2008 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page