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: Wed, 28 Jul 2004 15:14:09 +0100 Message-ID: References: <2mjr94Fnc903U1@uni-berlin.de> <2mnfg2Fpcd2uU1@uni-berlin.de> 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 8wgso7FVb9SGp2G7MEdM5QhXnZN0Ioht3jHae0y31XKMfGaDg= User-Agent: Opera M2/7.51 (Win32, build 3798) Xref: g2news1.google.com comp.lang.ada:2443 Date: 2004-07-28T15:14:09+01:00 List-Id: On Tue, 27 Jul 2004 18:52:11 +0200, Jano wrote: > ... > 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, ... I think there is generally great value in using an ATC to provide a timeout to a call to a service which is external (to the program or module), since this helps to ensure that your program or module is not stymied by something outside its control, as well as protecting against 'big ring' deadlock. I find that the gory details can be neatly hidden inside a procedure, to which you pass -- in addition to other relevant parameters -- the timeout value, which can have a convenient default. > Are queued entry calls abortable? I seem to remember something > about that. There are various rules and caveats. An entry call can be cancelled if it is still waiting in the queue, but the body of an accept statement is an 'abort deferred region', and cannot be aborted as such. An ATC is not permitted within any abort deferred region, which includes Initialize, Finalize, and Adjust. And so on. > I find the client (tasks)/server (monitors) architecture safe > and convenient, if you can stick to it... Indeed. -- Thanks for your reply, Nick Roberts