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: "Marc A. Criley" <mcNOSPAM@mckae.com>
Newsgroups: comp.lang.ada
Subject: Re: Deadlock resolution
Date: Mon, 26 Jul 2004 09:05:23 -0500
Message-ID: <2mkhd9Fnpr15U1@uni-berlin.de>
References: <opsbp6g9xzp4pfvb@bram-2>
X-Trace: news.uni-berlin.de ib4r7le/5XBPm7hgq+H3Ew4PGCQ5TcKAa42N1kHJz6ibX7ir60
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Xref: g2news1.google.com comp.lang.ada:2398
Date: 2004-07-26T09:05:23-05:00
List-Id: <comp.lang.ada>


"Nick Roberts" <nick.roberts@acm.org> wrote:

> I would appreciate answers from people who have experience
> of real life multi-tasking software written in Ada.

That would be me :-)

> 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)?

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.

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

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.

By coarse granularity I mean that the tasks did signficant amounts of work
on their own and the number of rendezvous were limited, which reduces the
opportunity for deadlock and makes finding it if/when it does occur a lot
easier. This is in contrast to the original implementation of the system
that 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.

Marc A. Criley
McKae Technologies
www.mckae.com