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.

Complex Events

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

We use the detective to discover that an event has occurred.


Code could be

  Send( part1 );
  Send( part2 );
  Send( master );


Code above doesn't work! Try instead

  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.


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

Who is the client of the detective

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


Not multually exclusive



  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

Possible send-blocking can be detected at compile time


Livelock (Deadly embrace)

Resource contention


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: