CS452 - Real-Time Programming - Fall 2008

Lecture 22 - Pathologies

Questions & Comment

Pathologies

1. Deadlock

2. Livelock (Deadly Embrace)

3. 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

1. Small changes in priorities change execution unpredictably, and drastically.
2. Debugging output changes execution drastically.

Solutions

1. 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.
2. At initialization it's a programming bug,
   • which can be discovered by gating

4. Performance

Local Delay

Client sends a request to a server, which it can't handle immediately. What should the server do?

1. Wait until it can handle the request, then Reply with the response.
   • Hold off other requests while waiting.
2. Reply immediately saying that the request cannot be handled.
   • But the client polls.
3. Queue the client until the request can be handled
   • Servicing other requests in the meantime.
4. Spawn a worker and let the client get the result from the worker.

Remote Delay

Client sends a request to a server, which requires service from another server.

• Like deadly embrace
• Is there a solution that
  • does not stop the server

  AND

  • does not stope the client
• Yes:
  • Create a worker
  • Reply the Tid of the worker to the client
  • Is it possible to predict how long it will take to acquire what's needed from the other server?

Priority

1. Priority inversion
2. One resource, many clients

Congestion

1. 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

Return to:

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