CS452 - Real-Time Programming - Spring 2008
Lecture 28 - Pathologies
Questions & Comment
- Statistical prediction
- Control theory
Pathologies
Not multually exclusive
Deadlock
Examples
- Task sends to itself (local: rest of system keeps running, task itself
will never run)
- Every task does Receive( ) (global: nothing is running)
- 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
- cycle in the send graph of all sends that could happen
- doesn't necessarily occur at run-time
- that is, it's a necessary but not sufficient condition
Solutions
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
Kernel cannot easily detect this
Possible solutions
- both resources in one proprietor
- global order on resource requests
- ethernet algorithm
Could consider this a form of critical race.
Critical Races
Theory of relativity and the event horizon
One task tests a condition
- takes an action based on that condition
- which will remedy it
Another task tests the same condition
- takes an action to remedy the condition
And the two actions are incompatible.
That is, information about the action of the first task did not spread
instantaneously:
- that race between the information and the second task's test was won by
the test.
Concrete example.
Engineer sends to switchDetective
- gets back, 'No such task.'
- Creates a switchDetective
- starts interacting with switchDetective using the Pid returned by
Create
Before switchDetective does RegisterAs, a second Engineer sends to
switchDetective
- gets back, 'No such task.'
- Creates a switchDetective
- starts interacting with switchDetective using the Pid returned by
Create
Each switchDetective, or its courier, does Put and Get to find out about
switches.
This is only a little bad, you probably won't even notice it, except your
performance will be bad.
But it can be much worse
- consider having two copies of a task that does track reservations.
Symptoms
- Small changes in priorities change execution unpredictably, and
drastically.
- Debugging output changes execution drastically.
Solutions
- A protocol for using the name server
- e.g. RegisterAs returns the Pid of an existing task
- if it's the one that is known to be bad, then do
ForceRegisterAs
- otherwise use the existing one.
- At initialization it's a programming bug,
- which can be discovered by gating
Performance Pathologies
Priority
- Priority inversion
- One resource, many clients
Congestion
- Too many tasks
- blocked tasks don't count,
- lowest priority tasks almost don't count
- Layered abstraction are costly
- e.g. Notifier -> SerialServer -> InputAccumulater ->
Parser -> TrackServer
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( ), an extra primitive, is a more efficient alternative.
Return to: