CS452 - Real-Time Programming - Spring 2008

Lecture 27 - The Detective

Questions & Comment

1. Kernel hand-in

Server Structure

The Detective

Simple Events

The notifier is a task that waits on events.

• AwaitEvent is like Receive

  It has two features

  • a simple, kernel-defined event that it waits on, more like ReceiveSpecific
  • can only serve one master
• Maybe AwaitEvent is more like Send
  • hardware/kernel is like Receive/Reply
• The notifier needs to reply that the event has happened
  • which it does using Send

    FOREVER {
      AwaitEvent( );
      Send( master );
    }

  • could it use Receive( )?

    FOREVER {
      Receive ( *requester );
      AwaitEvent( );
      Reply ( requester );
    }

    Does this ever make sense?

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 an 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

FOREVER {
  Receive( *requester, request );
  if ( request.type == CLIENT ) {
    parse( request );
    if ( happened( parsedRequest, DB ) ) Reply( requester );
    else enQueue( request );
  }
  else if (request.type == NOTIFICATION ) {
    updateDB ( request );
    Reply( requester );
    foreach ( queuedClient ) if ( happened( parsedRequest, DB ) ) Reply( client );
  }
}

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

1. Initiator of a normal action
2. Housekeeper of the system who will clean up pathologies (Idletask?))

Pathologies

Not multually exclusive

Deadlock

Examples

1. Task sends to itself (local: rest of system keeps running, task itself will never run)
2. Every task does Receive( ) (global: nothing is running)
3. Cycle of tasks sending around the cycle (local: other tasks keep running)

Kernel can detect such things

• What does it do?

Possible send-blocking can be detected at compile time

• cycle in the send graph of all sends that could happen
  • remember implicit sends
• doesn't necessarily occur at run-time
  • that is, it's a necessary but not sufficient condition

Solutions

• Gating
• Couriers

Livelock (Deadly embrace)

Resource contention

Example

• c1 needs r1 & r2; obtains r1 from p1; asks p2 for r2
• c2 needs r1 & r2; obtains r2 from p2; asks p1 for r1
• state:
  • c1, c2: SEND-BLOCKED - can't release resources
  • r1, r2: RECEIVE-BLOCKED - waiting for release
• r1 & r2 fail the requests
  • can just happen again

Kernel cannot easily detect this

Possible solutions

1. both resources in one proprietor
2. global order on resource requests
3. ethernet algorithm

Could consider this a form of critical race.

Critical Races

Server Structure

The Assassin

A unique task that is licensed to execute Destroy

The Doctor

Destory/Create is a common way to resolve malfunctions

Reset if a more efficient alternative.

Return to:

• Bill Cowan's Winter 2008 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page