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:31:14 +0100 Message-ID: References: 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 dYyS+TkyV33L3e5XDP0hfQFvk1FZmoGXolJRbNWxYwTUSdlOU= User-Agent: Opera M2/7.51 (Win32, build 3798) Xref: g2news1.google.com comp.lang.ada:2417 Date: 2004-07-27T16:31:14+01:00 List-Id: On 26 Jul 2004 09:46:48 +0200, Mark Lorenzen wrote: >> Does this software tend to have deadlock detection and/or >> resolution mechanisms explicitly programmed in Ada, or is >> it expected that deadlocks will be managed elsewhere (for >> example, in the operating system or run time system or >> RTMS or whatever)? > > I would say that it should be managed elsewhere preferably > by hardware. I have never come across hardware that does deadlock detection or resolution. Is there any information about this on the Internet? >> Alternatively, have you ever come across software written >> in Ada using techniques to eliminate deadlock (for example, >> a lock ordering strategy)? > > Use one of the normal analysis methods to analyse if your > tasks always meet their deadlines f.x. the Rate Monotonic > Analysis method (see "Meeting Deadlines in Hard Real-Time > Systems" ISBN: 0-8186-7406-7) together with the Ravenscar > Ada profile. Although I did not mention it (sorry), I am not really thinking about hard real time systems. The kind of systems I am most interested in are soft real time (non-embedded network server, technical workstation, office desktop). Although many of the same basic principles apply, it is often the case that the economics are slightly different. But perhaps this doesn't matter? >> Which approach do you think is best, in reality (handle in >> Ada, handle elsewhere, eliminate altogether)? > > Eliminate deadlocks in the first place is the best > solution. Everything else is just a hack trying to fix a > bad design. That is quite true, but deadlock handling is a bit like exception handling, in that it can form the braces of a belt- and-braces approach. Is deadlock elimination realistic for all kinds of software? >> I would appreciate brief descriptions of how deadlock >> detection and/or resolution is performed in real Ada >> programs (where it is performed in Ada). > > In some systems, a watchdog is monitoring the CPU to detect > if it halts and then resets the system. But again, avoiding > deadlocks is better than resetting the system. Is it necessary for the watchdog to reset the whole system, or just to kill one of the tasks/threads participating in the cycle of deadlock? -- Thanks again, Nick Roberts