CS452 - Real-Time Programming - Fall 2008

Lecture 18 - Task Structure

Questions & Comment

1. out 2

Task Structure

Server Notifier Buffer Courier

1. Simplest

1. Notifier
2. Server

Remember that all the calls provide error returns. You can/should use them for error recovery

• static error recovery: debugging
• dynamic error recovery: at run time

2. Using a Courier

Simplest is best

1. Notifier
   • Initialize

     // Initialize Hardware
     Receive( requester, eventId );
     Reply( requester );            // Should be the last thing before FOREVER
         

   • Work

     FOREVER {
       AwaitEvent( eventid );       //Should event ids be hard coded?
       // Acquire volatile data
       // Enable interrupts
       Receive( .... )
     }
      

2. Courier
   • Initialize

     Receive( requester, { notifierId, serverId } ); // Now knows the the server/notifier Pids
     Reply( requester );                             // Should be the last thing before FOREVER
             

   • Work

     FOREVER {
           Send( notifierPid ... );
           Send( serverPid ... );
         }

3. Server
   • Initialize

     notifierPid = Create( notifier );                 //Should notifier code name be hard coded?
     courierPid = Create( courier );
     Send( courierPid, { notifierPid, MyPid( ) } ... ) // On return courier is okay
     Send( notifierPid, eventId, ... );                 //On return notifier is okay
     RegisterAs( ); //On return requests can begin.
             

   • Work

     FOREVER {
       requesterPid = Receive( request );
       switch ( request.type ) {
       case COURIER:
         provideCourierService( ); // may release queued clients
         doReplies( );
       case CLIENT:
         if ( provideClientService( ) ) Reply( requesterPid );
         else enQueue( requesterPid );
       }
     }
         

This gets you through a bottleneck where no more than two events come too fast.

Remember that all the calls provide error returns. You can/should use them for error recovery

• static error recovery: debugging
• dynamic error recovery: at run time

3. Buffering

Add buffer before courier and server.

1. Notifier
   • Initialize

     // Initialize Hardware
     Receive( bufferPid )// Find server Pid
     Reply( ) // Should be the last thing before FOREVER
             

   • Work

     FOREVER {
       AwaitEvent( eventid );  //Should event ids be hard coded?
       // Acquire volatile data
       // Enable interrupts
       Send( bufferPid, .... )
     }
             

2. Buffer
   • Initialize

   • Work

     FOREVER {
       Receive( requesterPid, request );
       switch ( request.type ) {
       case COURIER:
         enQueue( queue, request.data );
         Reply( );
       case SERVER:
         Reply( queue );
       }
     }
             

3. Courier
   • Initialize

     Receive( requester, ..., bufferPid, ); // Now knows the the server/buffer Pids
     Reply( requester, ... );               // Should be the last thing before FOREVER
             

   • Work

     FOREVER {
       Send( bufferPid ... );
       Send( serverPid ... );
     }
             

4. Server
   • Initialize

     notifierPid = Create( notifier ); //Should notifier code name be hard coded?
     courierPid = Create( courier );
     bufferPid = Create( buffer );
     Send( courierPid, { myPid, bufferPid } ... ); // On return courier is okay
     Send( notifierPid, { bufferPid }, ... ); //On return notifier is okay
     RegisterAs( ); //On return requests can begin.
             

   • Work

     FOREVER {
       requesterPid = Receive( request );
       switch ( request.type ) {
       case COURIER:
         provideCourierService( ); // may release queued clients
         Reply( requesterPid );
         doReplies( );
       case CLIENT:
         if ( provideClientService( ) ) Reply( requesterPid );
         else enQueue( requesterPid );
       }
     }
         

4. Specialization

When there is a constant in a problem,

• there is always scope for gaining efficiency by specialization.

Example

One of your serial ports is always connected to the train

• Input from train, output to train, always have the same format

How to take advantage of this

• Put input into a struct

  typedef struct {
    int component;
    int instance;
    int report;
    int time;
  }

  The pass around the struct

• Where? At the lowest level possible.
• Consequence? Somebody
  • waits until several bytes have been received,
  • puts them into the struct,
  • passes along the struct

• If it's the notifier, you now have a TrainInputNotifier

  If it's the courier, you now have a TrainInputCourier

The tension between specialization and generality

• Advantages of generality
  • Write less code: more reuse, less debugging
  • Too much code that's never run
  • More likely to run in unforeseen circumstances
• Advantages of specialization
  • Write code that does less.
  • Do only what you need to do
  • Error detecting code can give more precise feedback

5. The Secretary

Think about the Server's send queue. It might have

• many requests from clients
• only a few requests from notifier(s)
• How likely is this to occur?
  • for a serial server
  • for a clock server

Possible solutions

1. Send queue priorities
   • opening a peanut with a sledge hammer
   • one more thing to tune
   • but... might have other uses
2. Ration access to clients using
   • a secretary, often called a guard, and
   • a courier

Possible code

1. Secretary

   initialize
   synchronize
   FOREVER {
     request = Receive( ... )
     switch ( request.type ) {
     case COURIER:
       status = FREE;
       waitingResult = request;
       Reply ( waiter, waitingResult );
       if ( !empty( requestQ ) ) {
         { waiter, waitingRequest } = dequeue( requestQ );
         Reply( courier, waitingRequest );
         status = BUSY;
       }
       break;
     case CLIENT:
       if ( status == BUSY ) {
         enqueue( requester, request );
       } else {
         Reply( courier, request );
         waiter = requester;
         status = BUSY;
       }
       break;
     }
   }

2. Courier

6. The Administrator

Return to:

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