CS452 - Real-Time Programming - Spring 2013

Lecture 13 - AwaitEvent, Task Structure

Pubilc Service Annoucements

1. Due date for kernel 3: 12 June.

Clock Server, Task Structure

A New Kernel Primitive: int AwaitEvent( int EventType )

How is AwaitEvent Used?

1. There should (almost) always be a task blocked on AwaitEvent for every interrupt type. Why?
2. A server cannot call AwaitEvent. Why?
3. We call the task that calls AwaitEvent a Notifier. Why?
4. Code for a typical Notifier

   void notifier( ) {
       // Initialization, find server, find evtType, initialize device
       FOREVER {
           data = AwaitEvent( evtType );
           Send( server, &data, ... );
       }
   }

5. Code for a typical server

   void server( ) {
       notifier = Create( HIGHEST, ... );
       // other initialization
       Send( notifier, &evtType, ... );
       FOREVER {
           Receive( &requester, &request, ... );
           switch ( request.type ) {
           case NOTIFIER:
               Reply( notifier );
               data = request.data;
               // use data
           case CLIENT:
               ...
           }
       }
   }

More About AwaitEvent

Argument

1. Somewhere there is a list of event types
   • List depends on hardware.
   • Application programmer knows the list.
     • Part of the API
   • Kernel can respond to each event type on the list
2. This is not very portable
   • The list would normally be the union of all types occurring on all hardware
   • This is the Windows problem

Processing in the kernel

• Initialization
  1. Kernel initialization has IRQ masked
  2. Kernel initializes ICU
  3. For each device
     1. Initialize whatever is not initialized in the notifier
  4. Kernel starts first user task
  5. Eventually, Notifier is created
  6. Notifier
     1. initializes device
     2. turns on interrupt(s) in the device
     3. turns on interrupt(s) in the ICU
     4. calls AwaitEvent

     1, 2 & 3, above, may be done either by the kernel or by the notifier

• Procedure
  1. Kernel
     1. identifies interrupt source
     2. identifies the correct Notifier
     3. acquires volatile data
     4. re-enables interrupt in the device
     5. re-enables interrupt in the CPU during task activation (eg, movs)
     6. puts volatile data into AwaitEvent's return value
     7. Makes Notifier ready
  2. Notifier
     1. collects and packages data
     2. sends to server
  3. Eventually Server
     1. Replies to Notifier
     2. Acts on the data
• Advantage
  • Clean consistent user code
• Disadvantage
  • Kernel has to know a lot about the hardware.
  • Hardware knowledge split between Notifier and kernel

HALT versus an Idle Task

What do you do when there are no tasks to run?

• Idle task
  • lowest priority
  • diagnose system: at least % of time idle should be known.
  • search for ETI
• HALT
  • turns off CPU clock
  • save power (battery)
  • provided two ways
    1. through System Controller Co-processor
    2. through the TS-7200 clock controller
  • IRQ path is asynchronous, so it works when the clock is off

Clock Server

Primitives

int Time( )

• Clock server starts at zero when it initializes
• Unit of time is tick

int Delay( int ticks )

• Note error returns
• You might want to add an error for negative arguments
  • ticks is usually calculated, and a negative value is an early warning of falling behind.

int DelayUntil( int ticks )

• Can be constructed from the above two primitives.

Pseudo-implementation

void clock( ) {
    // Create Notifier and send any initialization data
    // Initialize self
    FOREVER {
        Receive( &requester, &request, ... );
        switch ( request.type ) {
        case NOTIFIER:
            Reply( notifier, ... )
            // update time
        case TIME_REQUEST:
            Reply( requester, time,... )
        case DELAY_REQUEST: 
            // Add requester to list of suspended tasks
        }
        // Reply to any timed-out tasks
    }
}

Comments:

1. You need a common request data structure for client and notifier requests, or possibly a union.
2. You should notice a typical server pattern.
   • Server receives from Notifier
     • Data is used to update internal state.
     • Tasks currently suspended are checked
     • Any suspended client that can be service is given service.
   • Server receives from Client
     • If what the client wants is available the server gives service.
     • Otherwise the client is suspended.

It's common to sort the list of suspended tasks. Why?

• When does it pay off to keep a list sorted?

Return to:

• Bill Cowan's lecture notes for CS452 in s13
• Bill Cowan's Spring 2013 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page