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,FREEMAIL_FROM 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!news1.google.com!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local1.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Tue, 27 Jul 2004 16:29:16 -0500 Date: Tue, 27 Jul 2004 17:29:16 -0400 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Deadlock resolution References: <2mkhd9Fnpr15U1@uni-berlin.de> <2mnhrqFp0onrU1@uni-berlin.de> In-Reply-To: <2mnhrqFp0onrU1@uni-berlin.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.147.90.114 X-Trace: sv3-3jCmgn65DAJyAK6R2WM/WQSNMVEcNXkfAIIC7Nikt/Akj8F6i/TU4Q95FFa2Op237ksXwSf0QYSVHtb!BmYV44S7Eyn0BKLsofekqGmA5h+0eNP1un6oZ8N1i7rCsnY20Bh5/v7HeMi8bg== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.13 Xref: g2news1.google.com comp.lang.ada:2425 Date: 2004-07-27T17:29:16-04:00 List-Id: 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