CS452 - Real-Time Programming - Fall 2009

Lecture 22 - Task Structure: Detective

Reminders

H1N1

Servers and Attendant Tasks

1. Proprietor with a Notifier

2. Using a Courier

3. Using a Warehouse

4. Adding a Receptionist

5. Proprietor compared to Monitor

Controls a resource

data structure
hardware
etc.

Provides mutual exclusion by owning the code that accesses the resource

sequential code
ergo, easy

Proprietor provides service to clients

nameserver is an example.
one client is receiving service (REPLY-BLOCKED)
the others are waiting (RECEIVE-BLOCKED)
in this respect, like a monitor

Like a subroutine call to the client

does not facilitate concurrency
proprietor must fail requester if anything is missing

Proprietors versus Monitors


	Monitor	Proprietor	Comments
access to resource	localized	localized	Means one at a time.
service model	self-service	full-service	Easily adapted to multi-core
service structure	subroutine of client	independent task	Easily adapted to multi-core
priority	client	probably different	Do we want client priority or resource priority?
address space	client	separate	Hardware vs software protection
permissions	client	different	Does client have permission to run certain instructions?
CPU	same	could be different	Modern hardware works hard to support threads.

Generic Problem: Local Delay

Proprietor begins processing

discovers that it cannot complete

Can other requests be processed? Possible strategies

refusal
- client may poll
siblings
- pass requests along
- how does a client find the free one?
- how is state shared?
nested receive
- can block proprietor
- don't know that another client is waiting
early reply
- create worker to do work
- reply Pid of worker

6. Administrator, Worker

7. 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( request.type ) {
  case CLIENT:
    parsedRequest = parse( request );
    if ( happened( parsedRequest, DB ) ) Reply( requester );
    else insert( db, parsedRequest );
    break;
  case WORKER:
    updateDB ( request );
    Reply( requester );
    foreach ( queuedRequest )
      if ( happened( parsedRequest, DB ) ) { delete( parsedRequest ); Reply( client ); }
    break;
  }
}

This is the code of a detective.

Comments

The `code' above hides a lot of detail.
- How general can the expressions be?
- How general should they be?
- Could the detective spawn new workers for unforeseen requests?

We have done AND and OR.

Can we do NOT?
- You have to wait until the end of time to be certain that an event will not happen.

Usually you want to say something different

Something does not happen before a specific time

A specialized worker does Delay

Initialize;
Synchronize with detective;
WhoIs( "clockserver" );
FOREVER {
   Send( detective, {sequence-no, rrrrring}, {sequence-no, time}, ... );
   Delay( time );
}

Usually this is in an OR. The detective is something like

FOREVER {
   Receive( requester, ... );
   switch ( request-type ):
   case CLIENT: 
      insert( db, {requester, event, time} );
      if( !empty( evt-worker-Q ) ) Reply( dequeue( evt-worker-Q ), lookup-event( requester ) );
      else { enqueue( evtQ, requester ); Create( event-worker ); }
      if( !empty( alarm-worker-QQ ) ) Reply( dequeue( alarm-worker-Q ), lookup-time( requester ) );
      else { enqueue( evtQ, requester ); Create( alarm-worker ); }
      break;
   case EVT_WORKER:
      update( db, message );
      enqueue( event-worker-Q, requester );
      if( !empty( evtQ ) ) Reply( dequeue( event-worker-Q ), lookup-event( dequeue( evtQ ) ) );
      break;
   case ALARM_WORKER:
      update( db, message );
      enqueue( alarm-worker-Q, requester );
      if( !empty( evtQ ) ) Reply( dequeue( alarm-worker-Q ), lookup-time( dequeue( alarmQ ) ) );
      break;
   }
   while ( client = ready( db ) ) Reply( client, result );
}

Who is likely to be a detective's client?
- The initiator of an action
  - watching to see if a prediction is fulfilled or not.
- The housekeeper
  - who cleans up messes when they occur
  - could be the idle task
  .

Return to: