CS452 - Real-Time Programming - Fall 2010

Lecture 20 - Administrator, Detective

Public Service Announcements

Open house, November 9, 2010
Monday notes

Task Structure

Servers and Attendant Tasks

1. Proprietor with a Notifier

2. Using a Courier to Improve Receive

3. Using a Warehouse to Improve Transmit

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

4. The Secretary

Proprietor

Secretary

FOREVER {
    Receive( );
    switch ( )
    case courier && XMIT { (Reply, Reply) or enqueue }
    case courier && RCV { enqueue or (Reply, Reply) }
    case client && XMIT { (Reply, Reply) or enqueue }
    case client && RCV { enqueue or (Reply, Reply) }

Courier

FOREVER {
    Send( secretary )
    Send( prop )
}

5. Administrator, Worker

Generalization of proprietor

spawns workers to handle tasks

Administrator maintains an array of records

each record is a REPLY-BLOCKED task

Administrator works as he can on any one of the tasks.

Real administrators manage workers

static administrators create an array of unemployed workers in advance
dynamic administrators create workers as they need them

Worker code

  Receive( &bossTid, <initData> );
  Reply( bossTid, ... );
  FOREVER {
    Send( administrator, workResult, order );
    doWork( workOrder );
  }

Administrator code

Administrator( ) {
  Initialize( ); // orderQ, workerQ
  for ( i = 0; i < NUM_WORKERS; i++ ) worker[i] = Create( workerCode );
  for ( i = 0; i < NUM_WORKERS; i++ ) {
    Send( worker[i], initData , ... );
    enqueue( workerQ, worker[i] );
  }
  // RegisterAs
  FOREVER {
    error = Receive( requester, request );
    switch( request.type ) {
    case CLIENT: // enqueue w/o or Reply w/o
      enqueue( orderQ, workOrder = {requester, request}; {
      if( !empty( workerQ ) && available( <resources> ) )
         Reply( dequeue( workerQ ), { dequeue( orderQ ), <resources> );
      break;
    case WORKER: // Reply result, enqueue w'r or Reply w/o
      Reply( request.client, request.result );
      enqueue( workerQ, requester );
      if( !empty( orderQ ) && available( <resources> ))
        Reply( dequeue( workerQ ), { dequeue( orderQ ), <resources> } );
      break;
    }
  }
}

Alternative Administrator Code

Administrator( ) {
  Initialize( );
  for ( i = 0; i < NUM_WORKERS; i++ ) worker[i] = Create( workerCode );
  for ( i = 0; i < NUM_WORKERS; i++ ) Send( worker[i], ... , ... );
    // Initialize orderQueue, workerQueue
    // RegisterAs
  FOREVER {
    error = Receive( requester, request );
    switch( request.type ) {
    case CLIENT:
       enqueue ( workfifo, workorder );
       while ( !empty( workfifo ) )
          if ( complete ( workorder, data ) && workerTid = next( workerQ ) ) { 
             Reply( client, workerTid, ... );
             Reply( worker, workorder );
          }
       break;
    case WORKER:
      if( ( workOrder = deQueue( orderQueue) ) ) {
        workOrder = {workOrder.client, workOrder.request};
        Reply( requester, workOrder );
      } else enqueue( workerQueue, requester );
    }
  }
}

8. The Detective

Simple Events

The notifier is a task that waits on events.

AwaitEvent is like Send
It has two features
- a simple, kernel-defined event that it waits on
- hardware/kernel is like Receive/Reply
- can only serve one master
The notifier needs to pass on that the event has happened
- which it does using Send
```
FOREVER {
  AwaitEvent( eventId );
  Send( server );
}
```

You could call a notifier a detective,

who looks around on your behalf,
and let's you know when something you care about happens,
but really it is a detective's worker.

Complex Events

In an application there is likely to be lots of waiting on combinations of events.

form the combinations using Boolean operators

We use the detective to discover that a complex event has occurred.

How does the detective work?

Conjunction

Code could be

FOREVER {
  Send( part1 );
  Send( part2 );
  ...
  Send( master );
}

Disjunction

Code above doesn't work! Try instead

// InitializeDB;
// Create workers and synchronize;
// Synchronize with client;
FOREVER {
  Receive( *requester, request );
  switch ( reqest.type )
  case CLIENT:
    insert( reqQ, request );
    if ( happened( DB, request ) ) Reply( dequeue( reqQ ), ... );
    break;
  case WORKER:
    update ( DB, request );
    // Reply or enquqe requester
    foreach request in reqQ
      if ( happened( DB, request ) ) Reply( extract( reqQ ), ... );
    break;
}

This is the code of a detective.

Not

We can say that an event has not happened yet.

Only at the end of the universe can we say that an event simply has not happened.

Time-outs are needed for NOT

OR with Delay on the clock server.

Who is the client of the detective

Initiator of a normal action

Housekeeper of the system who will clean up pathologies (Idletask?))

Return to: