CS452 - Real-Time Programming - Spring 2008

Lecture 24 - Task Structure

Questions & Comment

1. Kernel assignment
2. out2 needs to be set
3. edge versus level-triggered at the input to the ICU

Task Structure

Server Notifier Buffer Courier

1. Simplest

1. Notifier
   • Initialize

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

   • Work

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

2. Server
   • Initialize

     notifierPid = Create( notifier ); //Should notifier code name be hard coded?
     Send( notifierPid, MyPid( ), ... ); //On return noifier is known to be okay
     RegisterAs( ); //On return requests can begin.
             

   • Work

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

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( )// Find courier Pid
     Reply( ) // Should be the last thing before FOREVER
         

   • Work

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

2. Server
   • Initialize

     notifierPid = Create( notifier ); //Should notifier code name be hard coded?
     courierPid = Create( courier );
     Send( courierPid, { notifierPid } ... ) // On return courier is okay
     Send( notifierPid, courierPid( ), ... ); //On return noifier is known to be 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 );
       }
     }
             

3. Courier
   • Initialize

     Receive( ) // Now knows the the server/notifier Pids
     Reply( server ) // Should be the last thing before FOREVER
             

   • Work

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

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 & courier between courier and server.

1. Buffer
   • Initialize

     // Doesn't need Pids
     // Needs to give out his Pid
             

   • Work

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

This structure clears up problems when the notifier runs too fast for the server.

Two issues:

1. Handles bottlenecks of all sizes.

   Define `bottleneck'.

2. Server could be buffered on the other side

   Called a guard.

What this amounts to is

• Server should be lean and hungry
  • do as little as possible
  • always be receive blocked

Administrator, Worker

Return to:

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