CS452 - Real-Time Programming - Fall 2009

Lecture 19 - Task Structure

Reminders

• Step by step implementation

Anthropomorphic Programming

We all, most programmers included, have effective intuitions about human relations

• We use them to `understand' pets,
• Why not programs?

Tasks are independent entities

• Understand them by thinking about them as if they have capabilities and goals.
• When you are developing something like the train application you are defining roles and relationships

Servers and Attendant Tasks

Why do servers need attendant tasks?

• What happens if a server calls AwaitEvent?

1. Proprietor with a Notifier

Proprietor `owns' a service, which usually means a resource.

• Think of the owner at the counter of an old-fashioned store
  • `store' means where things are stored;
  • it's in the back and only the proprietor can access it.
  • Many clients come to the front and are processed one by one.
  • Comment. The modern `store' is considered by many to be the most important innovation of the 20th century. (Yes, including the transistor, the computer, quantum mechanics, antibiotics, etc.) A whole lot of work that was previously done by store personnel is now done by the client. This is possible only because extensive codes of conduct have been internalized by clients. (That is, a large collection of new behaviour norms have been created and propagated.)
• Somebody has to sit out back waiting for the truck and bringing it to the proprietor

Kernel is handling hardware in this example

Notifier Code for a UART

• Initialize

  Receive( &serverTid, eventId );
  Reply( serverTid, ... );
      

• Work

  FOREVER {
    data = AwaitEvent( eventid );  // data includes event type and volatile data
    switch( event-type ) {
    case RCV_INT:
      Send( serverTid, {NOT_RCV, byte}, ... );
      break;
    case XMT_INT:
      // test transmitter?
      Send( serverTid, NOT_XMIT,  );  // byte is to be transmitted
      break;
    default:  // This will never happen because your kernel is bug-free.
  }

Proprietor/Notifier Code for a UART

• Initialize

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

• Work

  FOREVER {
    requesterTid = Receive( request, {request-type, data} );
    switch ( request-type ) {
    case NOT_RCV:
      Reply( requesterTid, ... );
      enqueue( rcvfifo, data );
      if ( ! empty( rcvQ ) ) Reply( dequeue( rcvQ ), dequeue( rcvfifo ) );
      break;
    case NOT_XMIT:
      Reply( requesterTid, ... );
      if ( ! empty( xmitfifo ) ) write( UART, dequeue( xmitfifo ) );
      else xmitRdy = true;
      break;
    case CLIENT_RCV:
      enqueue( rcvQ, requesterTid );
      if ( !empty( rcvfifo ) Reply( dequeue( rcvQ ), dequeue( rcvfifo ) );
      break;
    case CLIENT_XMIT:
      Reply( requesterTid, ... );
      enqueue ( xmitfifo, data );
      if ( xmitRdy ) { write( UART, dequeue( xmitfifo ) ); xmitRdy = false; }
      break;
    default:
      Reply( requesterTid, "Sorry. I don't have any spare change.\n" );
    }
  }

Notes

1. Notifier is usually of higher priority than server
   • Notice the early reply in the proprietor
2. When, and how, do interrupts get turned on and/or cleared?
3. Who coordinates hardware ownership?
4. We have made the code
   • easy to break into parts
   • easy to extend

2. Using a Courier

Simplest is best

Notifier Code

• Initialize

  Receive( &courierTid, ... );
  Reply( courierTid, ... );
      

• Work

  FOREVER {
    Receive( &courierTid, ... );
    data = AwaitEvent( eventid );  // data includes event-type and volatile data
    switch( event-type ) {
    case RCV_INT:
      Reply( courierTid, data );
      break;
    case XMT_INT:
      // test transmitter?
      Reply( courierTid, NOT_XMIT,  );  // byte is to be transmitted
      break;
    default:  // This will never happen because your kernel is bug-free.
  }

Courier Code

• Initialize

  Receive( &serverTid, notifierTid, ... );
  Send( notifierTid, ... );
  Reply( serverTid );

• Work

  FOREVER {
    Send( notifierTid, ..., {req, data} );
    Send( serverTid, {req, data} );
  }

Proprietor Code

• Initialize

  // queues & fifos
  notifierTid = Create( notifier );     //Should notifier code name be hard coded?
  courierTid = Create( courier );
  Send( courierTid, notifierTid, ... ); // On return courier & notifier are known to be okay
  RegisterAs( );                        //On return client requests can begin.
          

• Work

  FOREVER {
    requesterTid = Receive( request, {request-type, data} );
    switch ( request-type ) {
    case NOT_RCV:
      Reply( requesterTid, ... );
      enqueue( rcvfifo, data );
      if ( ! empty( rcvQ ) ) Reply( dequeue( rcvQ ), dequeue( rcvfifo ) );
      break;
    case NOT_XMIT:
      Reply( requesterTid, ... );
      if ( ! empty( xmitfifo ) ) write( UART, dequeue( xmitfifo ) );
      else xmitRdy = true;
      break;
    case CLIENT_RCV:
      enqueue( rcvQ, requesterTid );
      if ( !empty( rcvfifo ) Reply( dequeue( rcvQ ), dequeue( rcvfifo ) );
      break;
    case CLIENT_XMIT:
      Reply( requesterTid, ... );
      enqueue ( xmitfifo, data );
      if ( xmitRdy ) { write( UART, dequeue( xmitfifo ) ); xmitRdy = false; }
      break;
    default:
      Reply( requesterTid, "Sorry. I don't have any spare change.\n" );
    }
  }

Notes

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

Another possible arrangement for initialization

• Server Receives
• Courier sends to its parentTid
• Notifier sends to its parentTid

Distributed gating

3. Using a Warehouse

Add a warehouse between the courier and the notifier.

Notifier Code

• Initialize

  Receive( &warhouseTid, ... );
  Reply( warhouseTid, ... );
      

• Work

  FOREVER {
    data = AwaitEvent( eventid );  // data includes event-type and volatile data
    switch( event-type ) {
    case RCV_INT:
      Send( warehouseTid, data );
      break;
    case XMT_INT:
      // test transmitter?
      Reply( warehouseTid, NOT_XMIT,  );  // byte is to be transmitted
      break;
    default:  // This will never happen because your kernel is bug-free.
  }

Warehouse Code

• Initialize

  // data structures
  Receive( &courierTid, notifierTid, ... );
  Send( notifierTid, ... );
  Reply( courierTid, ... );

• Work

  FOREVER {
     Receive( &requester, {req-type, data}, );
     switch( req-type ) {
     case COUR_RCV:
        enqueue( rcvQ, requester );
        if( !empty( msgbuf ) ) Reply( dequeue( rcvQ ), extract( msgbuf ), ... );
        break;
     case COUR_XMIT:
        Reply( requester, ... );
        enqueue( xmitfifo, unpack( data ) );
        if ( xmitRdy ) { write( UART, dequeue( xmitfifo ) ); xmitRdy = false; }
        break;
     case NOT_RCV:
        Reply( requester , ... );
        install( msgbuf, pack( data ) );
        if( !empty( rcvQ ) && !empty( msgfifo ) ) Reply( dequeue( rcvQ ), extract( msgbuf ), );
        break;
     case NOT_XMIT:
        Reply( requester, ... );
        if( !empty( xmitfifo ) ) write( UART, dequeue( xmitfifo ) );
        else xmitRdy = true;
        break;
     default:
     }
  }

Courier Code

• Initialize

  Receive( &serverTid, {notifierTid, warehouseTid} ... );
  Send( warehouseTid, notifierTid, ... );
  Reply( serverTid );

• Work

  FOREVER {
    Send( warehouseTid, {req, data} );
    Send( serverTid, {req, data} );
  }

Proprietor Code

• Initialize

  // queues & fifos
  notifierTid = Create( notifier );     // Should notifier code name be hard coded?
  warehouseTid = Create( warehouse );
  courierTid = Create( courier );
  Send( courierTid, notifierTid, ... ); // On return courier, warehouse & notifier are known to be okay
  RegisterAs( );                        // On return client requests can begin.
          

• Work

  FOREVER {
    Receive( &requesterTid, {request-type, data} );
    switch ( request-type ) {
    case COUR_RCV:
      Reply( requesterTid, ... );
      enqueue( rcvfifo, data );
      if ( !empty( rcvQ ) ) Reply( dequeue( rcvQ ), dequeue( rcvfifo ) );
      break;
    case COUR_XMIT:
      enqueue( xmitQ, requesterTid );
      if ( !empty( xmitfifo ) ) Reply( dequeue( xmitQ ), dequeue( xmitfifo ) );
      break;
    case CLIENT_RCV:
      enqueue( rcvQ, requesterTid );
      if ( !empty( rcvfifo ) ) Reply( dequeue( rcvQ ), dequeue( rcvfifo ) );
      break;
    case CLIENT_XMIT:
      Reply( requesterTid, ... );
      enqueue( xmitfifo, data );
      if ( !empty( xmitQ ) ) Reply( dequeue( xmitQ ), dequeue( xmitfifo ) );
      break;
    default:
      Reply( requesterTid, "Sorry. I don't have any spare change.\n" );
    }
  }

Note

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

• Warehouse and proprietor are sharing the work.
• Could replace the server by a secretary & call the warehouse the server.
  • Compare the task structure

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

Return to:

• Bill Cowan's CS452 lecture note page for Fall 2009
• Bill Cowan's Fall 2009 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page