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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,3e11ef4efc073f6b X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!newsfeed.stanford.edu!newsfeed.berkeley.edu!ucberkeley!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: requeue with abort and timed call Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <2a60b044-6a5c-4ce6-93e6-6eeefc8806c3@l33g2000pri.googlegroups.com> <1f6rcb1qwt7vx.1mckzyk9ucohf.dlg@40tude.net> <84c56781-1cb1-4d86-be14-e66fc9fdade6@w1g2000prk.googlegroups.com> <4c7abc6f-d6d3-4265-8311-1bbb40cc0c0a@z27g2000prd.googlegroups.com> Date: Mon, 29 Dec 2008 11:55:09 +0100 Message-ID: <94gmm8tk6t6c$.1ngnma4ovauei.dlg@40tude.net> NNTP-Posting-Date: 29 Dec 2008 11:55:13 CET NNTP-Posting-Host: 975b9b07.newsspool3.arcor-online.net X-Trace: DXC=J3=ZJVak^FLAa;:RKVJ>LEMcF=Q^Z^V3H4Fo<]lROoRA^YC2XCjHcbIaQl;?6Gb3NODNcfSJ;bb[EIRnRBaCd:N X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:4077 Date: 2008-12-29T11:55:13+01:00 List-Id: On Mon, 29 Dec 2008 02:23:21 -0800 (PST), christoph.grein@eurocopter.com wrote: > On 28 Dez., 18:46, ishik...@arielworks.com wrote: >> But, please think about following code. >> Sometimes we cannot decide how long time procedures take. >> For example, if "Procedure_Tkaes_0sec_to_60sec" takes for 0.3 or to >> 0.0999..., Requeued_Call will be aborted. >> but, if it takes over 1 sec, Requeued_Class will be not aborted >> forever. >> This behavior is repugnant, I think. > > I think this is very idea behind a timed entry call - to be aborted, a > call must be queued when the delay expires; when it executes, it will > not be aborted. > > Imagine you are waiting in a queue. If you are not serviced within a > certain time (there is still someone before you), you leave the queue > ("or delay", including the case that you have been partly serviced and > are now waiting in another queue, i.e. "requeue with delay"). > > If you are serviced, but the service takes too long, you quit the > service - this is the asynchronous select (the one with "then abort"). No, apart from the race condition issue, the OP has already mentioned, the call is not serviced. Servicing was initiated by accepting the entry call, but then it was postponed using requeue. My understanding is that for the observer (the caller) servicing is semantically an atomic operation which ends with the last rendzevous or protected action. It is not abortable during a rendezvous or a protected action, but between them it well is (unless it was requeued without abort). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de