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: Jano <notelacreas@porfavor.no>
Newsgroups: comp.lang.ada
Subject: Re: Deadlock resolution
Date: Tue, 27 Jul 2004 18:52:11 +0200
Message-ID: <2mnfg2Fpcd2uU1@uni-berlin.de>
References: <opsbp6g9xzp4pfvb@bram-2> <2mjr94Fnc903U1@uni-berlin.de>
 <opsbsytrf6p4pfvb@bram-2>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.uni-berlin.de jKuO8TvfpeAYd2QqTQxBMAJbkzoNcuLxd+Ht5J0JusFeThTZQ=
User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626)
X-Accept-Language: en-us, en
In-Reply-To: <opsbsytrf6p4pfvb@bram-2>
Xref: g2news1.google.com comp.lang.ada:2420
Date: 2004-07-27T18:52:11+02:00
List-Id: <comp.lang.ada>

Nick Roberts wrote:
> On Mon, 26 Jul 2004 09:48:43 +0200, Jano <notelacreas@porfavor.no> wrote:
> 
>> Nick Roberts wrote:
>>
>>> 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 my case, I always try to play the safe way, and I tend to use the  
>> basic techniques I was taught when learning RT programming. Tasks 
>> share  data via monitors, and I don't use synchronous rendez-vous 
>> except where  this is a true need...
>>
>> In short, I prefer to not let deadlock to be a possibility.
> 
> 
> Okay, but in those cases where you do need to use rendezvouses (where
> deadlock might be a possibility)?

In short, I've never used a mitigation technique other than, when 
confronted with a deadlock, detecting the path to it and removing the cause.

In practice, I only remember to have suffered rendez-vous deadlock once, 
and it was confined to a single package still in early implementation 
stage, so it was easy to spot and remove.

I've been less lucky with circular deadlocks between two protected 
objects, but it was a temerity on my part because potentially blocking 
calls from protected objects shouldn't be performed. In fact it was an 
oversight on my part, solved once I saw what I was doing (!).

If I were extra paranoid about certain tasks and were to detect 
deadlocks, as a first though I suppose I would use the ATC construct, 
something like that:

select
    delay Timeout_Period;
    Report ("TIMEOUT IN RENDEZVOUS BLAHBLAH");
then abort
    Other_Task.Rendez_Vous;
    -- may be you can here
    abort Other_Task;
    -- or something else
end;

Are queued entry calls abortable? I seem to remember something about that.

I find the client (tasks)/server (monitors) architecture safe and 
convenient, if you can stick to it...