CS452 - Real-Time Programming - Spring 2010

Public Interest Announcements

Lecture 14 - Clock Server, Task Structure

How is AwaitEvent Used?

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

Code for a typical Notifier

main( ) {
    Tid server;
    int evtType, data;
    Receive( &server, &evtType, ... );
    // Other initialization
    Reply( server, ... );
    FOREVER {
        data = AwaitEvent( evtType );
        Send( server, &data, ... );
    }
}

Code for a typical server

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

More About AwaitEvent

Argument

Somewhere there is a list of event types
- Application programmer knows the list
- Kernel can respond to each event type on the list
This is not very portable
- The list would normally be the union of all types occurring on all hardware
- This is the Windows problem

Return value

Related to three free choices above.

Strategy 1: Kernel does it all

Procedure
1. Kernel identifies interrupt source
2. Kernel identifies the correct Notifier
3. Kernel acquires volatile data
4. Kernel re-enables interrupt in the device
5. Kernel re-enables interrupt in the ICU
6. Kernel re-enables interrupt in the CPU during task activation (eg, movs)
Return value contains the volatile data
Advantage
- Clean consistent user code
Disadvantage
- Kernel has to know a lot about the hardware.

Strategy 2: Notifier does most of it

Procedure
1. Kernel identifies interrupt source
2. Kernel identifies correct Notifier
3. Kernel activates Notifier
  - Notifier runs with interrupts disabled
4. Notifier acquires volatile data
5. Notifier re-enables interrupt in device
6. Notifier re-enables interrupt in ICU
7. Notifier Sends to Server
  - Interrupts are enabled when the kernel next schedules
8. Send completes
  - Interrupts are again disabled
9. Notifier calls AwaitEvent
  - Interrupts are enabled when the kernel next schedules
The second disbling of interrupts seems unnecessary. Why do we do it?
Advantage
- Knowledge of hardware removed from kernel, isolated in Notifier
Disadvantage
- Interrupts are disabled for longer. How much longer?

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.

Implementation

main( ) {
    notifier = Create( HIGHEST, ... );
    time = 0
    Send( notifier, &evtType, ... );
    FOREVER {
        Receive( &requester, &request, ... );
        switch ( request.type ) {
        case NOTIFIER:
            time++;
            Reply( notifier, ... );
            break;
        case TIME_REQUEST:
            Reply( requester, time,... ) 
            ...
        }
    }
}

Comments:

You need a common request type, or possibly a union.

Return to: