Re: Deadlock resolution

[Jano <notelacreas@porfavor.no>]

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...