CS452 - Real-Time Programming - Winter 2013

Lecture 21 - Task Structure

Pubilc Service Annoucements

1. First train control demo: 7 March.
2. Your routing should be able to find routes that require reversing.
3. Your interface should show
   • the fraction of CPU bandwidth used by the idle task,
   • the amount by which your calibration was off at the last sensor you passed
4. Exam: 16.00, 11 April to 18.30 12 April.

Anthropomorphic Programming

We all, even most programmers (!), have effective intuitions about human relations

• We use them to `understand' pets, which means attributing to them
  • goals
  • knowledge
  • capability
  • emotions
• Why not programs?
  • apply them to intertask relationships

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 economically 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 put it in "storage area" of the store.
  • In this example it's the the Notifier getting hardware events.

SOME Notifier Code for a UART

• Initialize

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

• Work

  FOREVER {
    data = AwaitEvent( eventid );  // data includes event type and volatile data
    switch( data.event-type ) {
    case RCV_INT:
      Send( serverTid, {NOT_RCV, data.byte}, ... );
      break;
    case XMT_INT:
      // transmit interrupt was masked in the UART by the kernel
      Send( serverTid, {NOT_XMIT}, byte );  // byte is to be transmitted
      store( UART..., byte )
      // unmask transmit interrupt
      break;
  }

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:
      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;
    }
  }

Notes

1. Notifier is usually of higher priority than server
   • Notice the early reply in the receive branch of the proprietorInterrupts get turned on and/or cleared?
2. When, how and by whom are the interrupts enabled, disabled and masked?
3. Who coordinates hardware ownership?
4. We have made the code
   • exhibit duality explicitly
   • easy to break into parts
   • avoided unnecessary tests and branches to make it easy to extend

2. Using a Courier

Why? Occasionally two events come close together and you want to be able to handle the first one as quickly as possibl

Simplest is best

Transmit Notifier Code

• Initialize

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

• Work

  FOREVER {
    data = AwaitEvent( eventid );
    Receive( &courierTid, byte );
    Reply( courierTid, NOT_XMIT,  );
    load( UART, byte );
  }

Transmit Courier Code

• Initialize

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

• Work

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

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 will begin.
          

• Work

  FOREVER {
    requesterTid = Receive( request, {request-type, data} );
    switch ( request-type ) {
    case NOT_XMIT:
      enqueue( requesterTid, xmitQ )
      if ( ! empty( xmitFifo ) ) Reply( dequeue( xmitQ ), dequeue( xmitFifo ) );
      break;
    case CLIENT_XMIT:
      Reply( requesterTid, ... );
      enqueue ( xmitFifo, data );
      if ( ! empty( xmitQ ) ) Reply( dequeue( xmitQ ), dequeue( xmitFifo ) );
      break;
    default:
      ASSERT( "..." );
    }
  }

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 task creation

• Server creates the courier
• Courier creates the notifier

Another possible arrangement for initialization

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

Distributed gating

I am showing you collections of tasks implemented together because sets of related tasks is a level of organization above the individual task.

E.g., the decision to add a courier requires revision of code within the group, but not outside it.

3. Using a Warehouse

Add a warehouse between the courier and the notifier.

The pseudo-code given is for receiving.

Notifier Code

• Initialize

  Receive( &warhouseTid, ... );
  Reply( warhouseTid, ... );
  msg.type = NOT_RCV;
      

• Work

  FOREVER {
    msg.data = AwaitEvent( eventid );
    Send( warehouseTid, msg, msg );
  }

Warehouse Code

• Initialize

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

• Work

  FOREVER {
     Receive( &requester, msg );
     switch( msg.type ) {
     case NOT_RCV:
        Reply( requester, msg );
        // insert data into package
        enqueue( pkgQ, package );
        if ( !empty( courQ ) ) { dequeue( courQ ), extract( pkgQ ) };
     case COUR_RCV:
        enqueue( courQ, requester );
        if( !empty( pkgQ ) ) Reply( dequeue( courQ ), dequeue( pkgQ ) );
     }
  }

Courier Code

• Initialize

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

• Work

  FOREVER {
    Send( warehouseTid, pkg );
    Send( serverTid, pkg );
  }

Proprietor Code

• Initialize

  // queues & fifos
  notifierTid = Create( notifier );
  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, pkg );
    switch ( pkg.type ) {
    case COUR_RCV:
      Reply( requesterTid, pkg );
      enqueue( pkgQ, pkg );
      if ( !empty( clientQ ) ) Reply( dequeue( clientQ ), dequeue( pkgQ ) )
    case CLIENT_RCV:
      enqueue( clientQ, requester );
      if ( !empty( pkgQ ) ) Reply( dequeue( clientQ ), dequeue( pkgQ ) );
    }
  }

Note

This structure clears up most problems when a burst of requests to the server would leave the notifier waiting in a long sendQ.

• Warehouse and proprietor share the work.
  • Server's Tid is public; Warehouse's Tid is private.
• This is far from the only way to share the work. For example,
  • The server could be guarded by a receptionist (assistant) who ensures that another client request occurs only when the previous request is complete. Then the warehouse is unnecessary.

Two issues:

1. Handles bottlenecks of all sizes.

   Give a precise and quantitative definition of `bottleneck'.

2. Server could be buffered on the other side

   Called a guard.

What this amounts to is that a server should be lean and hungry

• do as little as possible
• always be receive blocked

Return to:

• Bill Cowan's lecture notes for CS452 in w13
• Bill Cowan's Spring 2012 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's homely page