CS452 - Real-Time Programming - Spring 2008

Lecture 16 - NameServer

Questions & Comment

1. Due dates now on the web.

int Send( Pid 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

   What can go wrong

   1. Illegal tid
   2. tid not an existing task
   3. Too small receive buffer: this creates a little what to do question
   4. Too small reply buffer: What to do?
      • Common to put into the rply buffer what bytes can be put there and signal an error
      • Sending task might be able to do something useful

   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?
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( Pid *tid, char *arg-buffer, int arg-buffer-length )

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. Are errors possible?
   • What if the buffer wasn't big enough?
3. If several tasks have Sended, which one gets Received first?

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

These are pretty self explanatory

Sequence of states

Send before Receive

1. Sender sends and becomes send-blocked
2. Receiver receives
   • Sender becomes reply-blocked
   • Receiver remains ready
3. Receiver replies
   • Sender becomes ready
   • Receiver remains ready

Receive before Send

1. Receiver receives and becomes receive-blocked
2. Sender sends
   • Sender becomes reply-blocked
   • Receiver becomes ready
3. Receiver replies
   • Sender becomes ready
   • Receiver remains ready

Implementation

Code should be constant time

Send before Receive

• Kernel needs to find the Sender
• Need a FIFO Send queue in the Receiver's TD

Receive before Send

• Tid of Receiver in the arguments
• Test state to know what state receiver is in

How is the message copying done?

Nameserver

Tasks need to get the Task IDs of tasks they don't know.

Done using a task outside the kernel, called the Nameserver

Basic functionality

• int RegisterAs( char* name )
• Pid WhoIs( char *name )

This creates a global name-space of task names

Semantics of name-space

• One task can have two names
• No two tasks can have the same name.

Implementation

Code is trivial, and doesn't matter very much how it is written. Why?

Only used during

• initialization
• error recovery

But do the best you can anyway.

The interesting question. How does a task find out the Pid of the NameServer?

• Every NameServer had the same Pid
• Kernel knows the Pid of the NameServer and inserts it into WhoIs( ), &c
• Kernel puts the Pid of the NameServer into the TD of every task it creates
• Kernel provides a WhoIsNameServer( ) system call.

Return to:

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