CS452 - Real-Time Programming - Spring 2009

Lecture 19 - Task Structure

Task Structure

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
Somebody has to sit out back waiting for the truck and bringing it to the proprietor

Proprietor Code

Initialize

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 );
  switch ( request.type ) {
  case NOTIFIER:
    Reply( notifier );
    updateDataStructures( );
    for each queued client {
      if( serviceable( client ) ) {
        provideService( client );
        Reply( client );
      }
    }
    break;
  case CLIENT:
    if ( serviceable( requester ) ) {
      provideService( requester );
      Reply( requesterTid );
    else enQueue( requester );
  }
}

Notifier Code

Initialize

// Initialize Hardware
Receive( requester, eventId );
Reply( requester );
EnableInterrupts( );      // In the device
                          // Should be the last thing before FOREVER

Work

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

Notes

Notifier is usually of higher priority than server
- Notice the early reply in the proprietor
When, and by whom, do interrupts get turned on in the CPU?
- Presumably the Notifier
  - configures the hardware
  - turns on interrupts in the hardware
  - enables interrupts in the VIC
Who coordinates hardware ownership?

2. Using a Courier

Simplest is best

Notifier

Initialize

// Initialize Hardware
Receive( requester, eventId );
Reply( requester );            // Should be the last thing before FOREVER

Work

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

Courier

Initialize

Receive( requester, { notifierId, serverId } ); // Now knows the the server/notifier Pids
Reply( requester );                             // Should be the last thing before FOREVER

Work

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

Server

Initialize

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

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

Add buffer before courier and server.

Notifier

Initialize

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

Work

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

Buffer

Initialize
```
        
```

Work

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

Courier

Initialize

Receive( requester, ..., bufferPid, ); // Now knows the the server/buffer Pids
Reply( requester, ... );               // Should be the last thing before FOREVER

Work

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

Server

Initialize

notifierPid = Create( notifier ); //Should notifier code name be hard coded?
courierPid = Create( courier );
bufferPid = Create( buffer );
Send( courierPid, { myPid, bufferPid } ... ); // On return courier is okay
Send( notifierPid, { bufferPid }, ... ); //On return notifier is okay
RegisterAs( ); //On return requests can begin.

Work

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

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

Two issues:

Handles bottlenecks of all sizes.
Define `bottleneck'.
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: