CS452 - Real-Time Programming - Fall 2010

Lecture 21 - Detective, Projects

Public Service Announcements

Open house, November 9, 2010

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

4. The Secretary

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?))

Assignments

1. Tracking

What you are expected to do

One locomotive on the track:
- Manually control train and switches
- Your application knows where the train is at all times.
  1. Where it stops after passing a sensor
  2. Where it stops while travelling at a constant speed
  3. Where it stops while accelerating or decelerating.
This should be robust against malfunctioning sensors and switches
To do this you need
- Calibration
- Route creation. In route creation routes in which the lomotive changes direction seem more clever.

2. Avoiding

What you are expected to do

Two or three locomotives on the track:
- Give each locomotive a destination & speed at the terminal.
- They find non-conflicting routes to their destinations and travel to them.
- Your application knows where the trains are at all times.
This should be robust against malfunctioning sensors and switches
- Locomotives should not collide
- Locomotives should not fuse into one when they get too close together
To do this you need
- Adaptive route finding
- A track reservation system

Projects

1. Train style

Give trains roles and objectives. For example,

Passenger train travels on a repetitive route meeting a schedule.
Freight train travels to random destinations as fast as possible.
Objective is to deliver as much freight as possible while keeping a passenger train on time.

Another example,

Trains are taxis.
When a load appears they race to see if they can get it

2. Game style

The track is a graph.

Several different ways to choose vertices and edges

Many games are played on graphs

Checkers, snakes & ladders, maze games, etc.
Implement a graph game played on the track graph.

E.g. watchmen and bandit.

Return to: