CS452 - Real-Time Programming - Spring 2011

Lecture 17 - Courier/Warehouse

Pubilic Service Announcement

1. Possible bottlenecks in Terminal/ARM/Train system
   • train controller
   • ARM train controller communication
   • user

Servers and Attendant Tasks

1. Proprietor with a Notifier

2. Using a Courier

Simplest is best

Transmit Notifier Code

• Initialize

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

• Work

  FOREVER {
    Receive( &courierTid, byte ); // The courier should almost always
                                  // be RCV_BL on the notifiers SendQ.
    load( UART..., byte )
    data = AwaitEvent( eventid );
    Reply( courierTid, NOT_XMIT,  );
  }

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.

• Give a precise definition of `too fast'.

This code, like the previous code, operates correctly if there is more than one notifier.

• What other things need to be rethought if there is oging to be more than notifier.

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
• Couier 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.

Notifier Code

• Initialize

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

• Work

  FOREVER {
    data = AwaitEvent( eventid );  // data includes event-type and volatile data
    switch( event-type ) {
    case XMT_INT:
      // test transmitter?
      Send( warehouseTid, NOT_XMIT, byte );  // byte is to be transmitted
      Write( UART, byte );
      break;
    default:  // 
      ASSERT( "This didn't happen because my 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 NOT_XMIT:
        enqueue( xmitQ, requester );
        if ( !empty( xmitFifo ) ) { Reply( extract( extract( xmitQ ), extract( xmitFifo ) };
        break;
     case COUR_XMIT:
        enqueue( courQ, requester );
        insert( xmitFifo, unpack( data ) );
        if( !empty( xmitQ ) ) Reply( extract( xmitQ ), extract( xmitFifo ) );
        if( empty( xmitFifo ) ) Reply( extract( courQ ), "Send more." )
        break;
     default:
       ASSERT( "This didn't happen because my kernel is bug-free." );
     }
  }

Transmit 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 );
  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_XMIT:
      enqueue( xmitQ, requesterTid );
      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( "This didn't happen because my kernel is bug-free." );
    }
  }

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

Server should be lean and hungry

• do as little as possible
• always be receive blocked

Debugging Real-time Programs

Stack Trace

In single-threaded programs this is often the most useful tool.

• Anything that terminates execution abnormally prints the set of active stack frames
• Minimal version
  • name of calling function
  • line number of call
• Extreme version
  • values of arguments
  • values of local variables

What is the equivalent of a stack trace in a real-time multi-tasking environment?

• How would you implement it?

  Two basic questions to answer.

  1. When is it produced?
  2. What should be in it?
• How would you make it readable?

Breakpoint

What does it do?

• snapshot of the system
  • This means that computation, including respose to interrupts, must stop, or it isn't a snapshot.
• provides interactive tools for examining kernel data structures, such as
  • task descriptors
  • lists and queues
  • stacks, including the program counter and local variables, of individual tasks
• restart system immediately afterwards
  • If you want to continue where processing stopped you must make certain that all state is saved when you enter Beakpoint and restored when you leave it. What about pending interrupts? You can't stop the entire universe!
  • Otherwise you can re-enter RedBoot.

How do you get it started?

• function call, which you insert in your code when compiling.
  • The easiest and fastest form to implement.
  • Having the call as part of ASSERT is common.
  • Has to exit to RedBoot. (Jump to x00.)
• system call instead of function call, which respects the kernel/user distinction.
• an exception triggered externally
  • at initialization
    1. Set up the system so that the external event will generate an exception
    2. E.g. attach a button to PDIO on the third connector, set up ICU.
  • at run-time
    1. Trigger the interrupt
    2. Switch to Breakpoint in the event handler
    3. Either exit to RedBoot,
    4. Or clean up pending interrupts and resume execution.

Breakpoint is a special case of a particular sort of tool that is very common.

• condition occurs => information is made available
• breakpoint provides the information interactively (`interactively' = `on the time scale of the user')
  • it can stop the system completely. How?
  • but it has limited ability to stop the real world
    • i.e., it hides some bugs

Getting information closer to real-time.

Return to:

• Bill Cowan's lecture notes for CS452 in s11
• Bill Cowan's Spring 2011 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page