Re: Deadlock resolution

["Nick Roberts" <nick.roberts@acm.org>]

On Mon, 26 Jul 2004 09:05:23 -0500, Marc A. Criley <mcNOSPAM@mckae.com>  
wrote:

> To be quite frank about it, I simply designed and implemented the code to
> preclude deadlocks. During development it sometimes happened, and the Ada
> RTS either detected it or everything just locked up, but the fix was
> to...well...go fix the bug the caused the deadlock.

Right, but can I presume you were pleased on those occasions when the RTS
did detect the deadlock?

> If you prevent the problem from happening, then you don't have to worry
> about the consequences of it happening.

I suppose it is a question of sureness. Would I be wrong in suggesting
that for some kinds of software it won't be possible to be 100% sure
that deadlock cannot occur?

> This was a command and control system, and some of the design aspects 
> that help avoid deadlock potential include using monitors to control
> access to critical data items and employing a coarse-grained
> partitioning of concurrent functionality.
> ...
> This is in contrast to the original implementation of the systemthat had  
> the system's functionality broken down into finely-grained bits
> that were almost constantly interacting with each other. May sound good  
> in theory (and may be for some kinds of systems), but the reality of
> that implementation made it awful to trace control flow through the
> system and debug time-related issues such as deadlock and starvation.

That's an interesting observation (thanks).

To my mind, parallelism is unimportant except for software which is
interacting with the outside world (either human beings or peripheral
devices, or an external network). Of course, software which is
interacting with software that is interacting with the outside world
can get caught up in this, and so much of an overall system can be.

I do get a bit annoyed when I observe application software (in a
windowing system) behaving in a clearly non parallelistic manner. I
might click on a button on one program telling it to download a file,
say, and then click on another button telling it to fetch my e-mail
only to find that it doesn't respond. These two things could and (to
my mind) should be do-able in parallel.

To concoct another example, if an air traffic control system detects
two conflicts at the same time, it should not (I suspect ;-) have to
wait for one to be resolved before popping the alarm for the other.

I'm all for eliminating unnecessary parallelism. It is certainly
inefficient and it usually makes a piece of software more complex
than it needs to be.

But I think parallelism is often necessary or desirable. Nothing
comes for free, and the price to pay for parallelism, as you rightly
point out, is the increased danger of deadlocks. For safety critical
(or otherwise critical) software, one might decide that the danger
is too great, and opt for the safety of a non parallel (or less
parallel) design. But with less critical software (e.g. a GUI for
an office desktop computer), perhaps the risk is worth it?

-- 
Many thanks,
Nick Roberts