From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,5dc0152fc17e5f2c X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: Deadlock resolution Date: Tue, 27 Jul 2004 16:50:51 +0100 Message-ID: References: <2mkhd9Fnpr15U1@uni-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: news.uni-berlin.de FfmN2LjVdn4WV61CAOgcdwM3Fr7jUKSSeHObXi2xMkdfl8P1k= User-Agent: Opera M2/7.51 (Win32, build 3798) Xref: g2news1.google.com comp.lang.ada:2419 Date: 2004-07-27T16:50:51+01:00 List-Id: On Mon, 26 Jul 2004 09:05:23 -0500, Marc A. Criley 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