Re: Deadlock resolution

["Robert I. Eachus" <rieachus@comcast.net>]

Marc A. Criley wrote:

>>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?
> 
> 
> I suppose that for the general case of all possible usable concurrent
> architectures that the answer would be "no", however, by suitably
> constraining the architecture and design it is certainly possible to
> eliminate the possibility of deadlock. Coarse-grained concurrency is one of
> the factors in doing just that.

We had a discussion here a few weeks back about how the Ada compilation 
order rules help manage concurrency so that deadlocks won't happen.  You 
can design in potential deadlocks if you want, or if for some reason you 
must, but Ada makes it pretty obvious what you are doing to yourself. 
In particular if you find yourself trying to interlock calls to two 
protected objects.

Oh, and as was pointed out in that discussion you do have to be careful 
when using protected objects.  However, that is not too hard in general. 
There is one 'mental' gotcha.  The rule in Ada is that potentially 
blocking calls in protected objects are bounded error. RM 9.5.1(8). 
Calls to some predefined IO programs (basically those that read from or 
  write to a file) are defined as potentially blocking, but most Ada 
compilers won't warn you about such calls inside a protected object. 
(Note that using Ada.Text_IO to read from or write to a String is okay.)

But 99% of the time, when I am designing an Ada package that controls or 
depends on concurrency, deadlock is just not a concern.  The protected 
objects or tasks in the package won't combine with other packages in any 
way that allows these constructs to be involved in a deadlock.  This 
makes avoiding deadlock a local issue instead of an emergent property of 
the whole system.

The other 1% of the time, the potential deadlock is not a software 
issue, and you just have to deal with the issues that causes.  I ran 
into this issue a couple of times in radar systems.  Let me see if I can 
distill an example down to understandable size.  In one particular 
system there were several "heads" (radar transmitters and receivers) 
controlled from a central control site.  For safety reasons the radar 
sites had to have hardware interlocks so that the radar transmitter 
could not be turned on while someone was in the radome.  This created 
potential deadlocks that could only be dealt with by "brute force."

True, these were extremely unlikely scenarios, but they had to be 
considered during the design.  For example, what if the radar was 
operating, and some component inside the radome fails preventing the 
remote operators from turning the radar off?  Solution, put in a power 
kill switch external to the radome, where maintenance personnel can get 
to it when the radar is on.  But that switch has to have other 
interlocks.  Another set of issues had to do with the power failing 
during testing of the computer memory.  (We had to insure that the 
memory tests never left the memory in a state that corresponded to the 
radar radiating, since the system could try to resume from the current 
state when the power came back on.)

-- 

                                           Robert I. Eachus

"The flames kindled on the Fourth of July, 1776, have spread over too 
much of the globe to be extinguished by the feeble engines of despotism; 
on the contrary, they will consume these engines and all who work them." 
-- Thomas Jefferson, 1821