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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6ff6ac051491e437 X-Google-Attributes: gid103376,public From: progers@acm.org Subject: Re: Question about the need for requeue as described in Rationale Date: 1996/07/10 Message-ID: <4s0g20$dca@uuneo.neosoft.com>#1/1 X-Deja-AN: 167587557 references: <31c8fdd4.5a455349@zesi.ruhr.de> <4rjimv$glk@portal.gmu.edu> <4rk1tb$lit@uuneo.neosoft.com> <31E16C28.3BE2@csehp3.mdc.com> organization: NeoSoft, Inc. reply-to: progers@acm.org newsgroups: comp.lang.ada Date: 1996-07-10T00:00:00+00:00 List-Id: In , bobduff@world.std.com (Robert A Duff) writes: >In article <31E16C28.3BE2@csehp3.mdc.com>, >James A. Squire wrote: >>How is this different from barrier conditions on protected entries and >>procedures? > >It's not different. The guards of an accept statement cannot reference >parameters of the entry call. The barrier of an entry body cannot >reference the parameters of the entry call. > >This illustrates the need for requeue. (Well, not *need*; exactly, I >guess it illustrates the *usefulness* of requeue.) > >Suppose you want to write a protected entry that accepts the caller >based on some condition, and that condition is based on the parameters >of the call, and also on the current state of the protected object. >Well, Ada doesn't support that, directly, so requeue gives you a way out >-- you can accept the call unconditionally, and then write some code >that checks all the relevant stuff, and either requeues-for-later, or >else does-it-now. That is an understatement, IMHO. When one looks at the code required to be safe from aborts and and cancellations -- which requires agent tasks -- requeue looks more like a necessity. True, that is overstatement, since it can be done without it, but realistically, no. pat --------------- Patrick Rogers progers@acm.org