CS452 - Real-Time Programming - Spring 2009
Lecture 22 - Task Structure
Task Structure: Destroy
8. Static versus Dynamic Task Structure
Recovering from errors
Why are C++ compilers so slow? Why are their executables to big?
- They are busy turning dynamic programming constructs into a static
program.
Static
- easy to program
- robust
- The code with the fewest errors is the code that was not
written.
- predictable
- inflexible
Dynamic
- hard to program
- fragile
- Much of the code runs very infrequently.
- unpredictable
- because they are trying to handle so many extra cases
- flexible
- flexibility is inversely correlated with efficiency
Destroy
Three things are hard about Destroy
- cleaning up in constant time
- Remove task from all queues
- priority queues
- send queues
- Unblock all tasks blocked on this task
- send blocked
- receive blocked
- reply blocked
- Destroy all tasks that have a specific relationship to this task
- requires Create discipline
- e.g. Parent tasks logically and Destroy all children
- How about Couriers?
- re-using resources in constant time
- task descriptor
- task id
- controlled hardware or data structures
- could we reuse the name server?
- Create may not be very fast
- It doesn't need to be fast if it is run once at the beginning and
that is all
9. 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
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 );
if ( request.type == CLIENT ) {
parsedRequest = parse( request );
if ( happened( parsedRequest, DB ) ) Reply( requester );
else enqueue( parsedRequest );
}
else if (request.type == WORKER ) {
updateDB ( request );
Reply( requester );
foreach ( queuedRequest )
if ( happened( parsedRequest, DB ) ) {
dequeue( parsedRequest );
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
- Initiator of a normal action
- Housekeeper of the system who will clean up pathologies
(Idletask?))
Return to: