CS452 - Real-Time Programming - Fall 2009

Lecture 20 - Task Structure: Warehouse, Receptionist

Reminders

H1N1

Servers and Attendant Tasks

Why do servers need attendant tasks?

What happens if a server calls AwaitEvent?

1. Proprietor with a Notifier

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.
  }
}

Comments
1. Receive passes a byte directly to the server.
2. Transmit could accept a byte which it writes, but this is left for the proprietor to do.
3. Writing the byte could be separated from buffering.

Proprietor Code for a UART

Initialize

// queues & fifos
notifierPid = Create( notifier );
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" );
  }
}

Comments
1. Early Reply to the Notifier means shorter times until the notifier is again waiting on the interrupt
2. Buffering is done inside the proprietor

Notes

Notifier is usually of higher priority than server
- Notice the early reply in the proprietor
When, and how, do interrupts get enabled and/or cleared?
- In this version, they are enabled all the timel.
- They are cleared by the kernel.
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.
  }
}

Comments
1. Wait is incremented by Receive blocked time.
2. After Reply Courier must Send to Proprietor, then Send again to Notifier.
3. Courier execution will wait until Notifier is Receive blocked.

Courier Code

Initialize

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

Work

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

Comments
1. data is empty when request is Transmit

Proprietor Code

Initialize

// queues & fifos
notifierTid = Create( notifier );
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 COUR_RCV:
    Reply( requesterTid, ... );
    enqueue( rcvfifo, data );
    if ( ! empty( rcvQ ) ) Reply( dequeue( rcvQ ), dequeue( rcvfifo ) );
    break;
  case COUR_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" );
  }
}

Comments

If write were done by Notifier & buffering by Proprietor we would have in the Proprietor

  case COUR_XMIT:
    if ( ! empty( xmitfifo ) ) Reply( requesterTid, { PROP_XMIT, UART, dequeue( xmitfifo ) } );
    else xmitRdy = true;
    break;
...
  case CLIENT_XMIT:
    Reply( requesterTid, ... );
    enqueue ( xmitfifo, data );
    if ( xmitRdy ) { 
      Reply( requesterTid, { PROP_XMIT, UART, dequeue( xmitfifo ) } );
      xmitRdy = false;
    } else Reply( RequesterTid, ... );
    break;

and n the Notifier

  Receive( &courierTid, { req-type, uart, byte }, ... );
  if ( req-type == PROP_XMIT ) write( uart, byte );

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?
    Send( 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:
   }
}

Comments
1. Early Reply ensures that the Notifier is once again waiting as soon as possible.
2. Because there is only one Courier that knows about the Warehouse there can never be more than task in the Warehouse SendQ.
3. Receiving data, the Warehouse is packing bytes into multibyte messages.
4. Transmitting data, the Warehouse is unpacking messages and writing bytes to the UART.
5. Additional configuration information could come during the initialization synchronization.

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, {warehouseTid, notifierTid}, ... ); 
                                      // On return courier, warehouse & notifier are known to be okay
RegisterAs( );                        // On return client requests can begin.

Work

FOREVER {
  Receive( &requesterTid, { request-type, message } );
  switch ( request-type ) {
  case COUR_RCV:
    Reply( requesterTid, ... );
    enqueue( rcvfifo, message );
    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, message );
    if ( !empty( xmitQ ) ) Reply( dequeue( xmitQ ), dequeue( xmitfifo ) );
    break;
  default:
    Reply( requesterTid, "Sorry. I don't have any spare change.\n" );
  }
}

Comments
1. The Proprietor is now dealing with multi-byte messages.

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
Messages passed through the Courier to the Proprietor are reduced in number

Two issues:

Handles bottlenecks of all sizes.
Define `bottleneck'.
Doesn't handle excessive ongoing message throughput

4. Adding a Receptionist

In the solution above there should be, on average,

one CLIENT_RCV per COUR_RCV
one CLIENT_XMIT per COUR_XMIT

We also know that the Warehouse will buffer messages coming and going from the hardware.

A task that can screen requests can lower the buffering required in the Proprietor. We call such a task a receptionist.

Receptionist Code

Initialize

// queues & fifos
propTid = MyParentTid( );
Send( propTid( ), ..., { notifierTid, warehouseTid, courierTid }, ... );
             // On return Proprietor is known to be okay
Send( courierTid, { notifierTid, warehouseTid }, ... );
             // On return courier, warehouse & notifier are known to be okay
RegisterAs( );                        // On return client requests can begin.

Work

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

Comments
1. The Proprietor is now dealing with multi-byte messages.

Proprietor Code

Initialize

// queues & fifos
notifierTid = Create( notifier );
warehouseTid = Create( warehouse );
courierTid = Create( courier );
receptionistTid = Create( receptionist );
Receive( &receptionistTid, ... );
Reply( receptionistTid, { notifierTid,warehouseTid, courierTid } ... );

Work

FOREVER {
  Send( receptionistTid, ..., { req-type, tid, message }, ... );
  switch ( req-type ) {
  case RCV:
    something( tid, message );
    Reply( tid, message );
    break;
  case XMIT:
    something( tid, message );
    Reply( tid, message );
    break;
  default:
    Twiddle-thumbs( );
  }
}

Comments
1. something( ) might be maintaining a database.
  - If so there could be tax inspectors wanting to access it.
  - Then the Send must become a Receive,
  - another Courier is needed, and
  - there would be more cases.

Note

Return to: