CS452 - Real-Time Programming - Fall 2010

Lecture 11 - Name Server

Pubilic Service Announcements

1. Kernel 1?
   • Hardware interrupts to come
2. Send/Receive/Reply
   • performance
   • no caches, no optimization

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
  • Typed as strings
    • which require formatting and parsing
  • Normally cast from pointers to structs
    • 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 should 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

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

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 Receive, immediately 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. If sendQ is not empty
   1. Extract sender from sendQ
   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.

Servers

What is a server?

• a task that provides service to any task that knows its task id.
• a task that owns a resource and provides synchronized access to it.
• above,
  • `a task' owns the interface
  • other tasks may do the work

How are servers implemented?

• Receive is the key
  • Receive a request
  • Reply the response
• Sender (client, task that is making the request) blocks until the response is available. That is, sender, in effect, is running at the priority of the server between the request and its reponse
  • Server priority should be set according to the importance of the service it supplies.
  • But client priority should be considered by the server. For example,
    • One set of instructions for higher priority client
    • One set of instructions for lower priority client

Name Server

What is a name server?

• There is a set of global execution-independent names
• There is a set of execution-dependent resources that provide services associated with the names
• Name server maintains an up-to-date table mapping names to resources
  • Accepts requests to update the table
  • Accepts queries concerning the table

Why Do We Need a Name Server

How do You Get the Task Id of the Name Server?

1. Make it a constant across executions

Name Server API

int RegisterAs( char *name );

• One task can be registered under two names.
• Each name is associated with a single task.
• Name is \000 terminated.

int WhoIs( char *name );

• Name is \000 terminated.

Name Server Semantics

RegisterAs

• Errors
  1. Not a legal name.
  2. tid is not a task
  3. tid is not the Name Server
  4. Already somebody registered with that name
     • What does the caller do?

WhoIs

• Errors
  1. Not a legal name.
  2. tid is not a task
  3. tid is not the Name Server
  4. No task registered under that name
     • What does the caller do?

Comments

• Are we likely to want an Unregister primitive?
• Perhaps RegisterAs should just overwrite.

Name Server Implementation

User Code

E.g., RegisterAs

typedef struct {
    int type;
    char *name;
} NSstruct;
int RegisterAs( char *name ) {
    int result;
    NSstruct req;
    req.type = REGISTERAS;
    req.name = name;
    bytes = Send( NSTid, &req, sizeof(NSstruct), (char *) result, sizeof(int) );
    if ( bytes != sizeof(int) ) {
        // Do something error-like
    } else return result;
}

There are lots of possible variations, and this one is by no means the best.

Server Code

typedef struct {
    int type;
    char *name;
} NSstruct;
int bytes, tid;
NSstruct req;
// initialize tables
FOREVER {
    bytes = Receive( &tid, &req, sizeof(NSstruct) );
    if ( bytes != sizeof(NSstruct) ) {
        // Reply with error
    } else {
        switch( req.type ) {
        case REGISTERAS:
            insert( name, tid );
            Reply( tid, SUCCESS, sizeof(int) );
            break;
        case WHOIS:
            result = lookup( name );
            Reply( tid, result, sizeof(int) );
            break;
        default
            Reply( tid, ERROR, sizeof(int) );
            break;
        }
    }
}

Comments

1. This code wouldn't work. Why?
2. How much will this code run?
   • When will it run?
3. How would you implement insert & lookup?
   • Figure out
     1. What deadlines does Nameserver have?
     2. How many names will be in NameServer?
     3. How many ReisterAs? and when?
     4. How many WhoIs? and when?
4. What should be allowable as a name?

Return to:

• Bill Cowan's lecture notes for CS452 in f10
• Bill Cowan's Fall 2010 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page