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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	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: bobduff@world.std.com (Robert A Duff)
Subject: Re: Question about the need for requeue as described in Rationale
Date: 1996/07/10
Message-ID: <DuAyGJ.ACx@world.std.com>#1/1
X-Deja-AN: 167493012
references: <31c8fdd4.5a455349@zesi.ruhr.de> <4rjimv$glk@portal.gmu.edu>
 <4rk1tb$lit@uuneo.neosoft.com> <31E16C28.3BE2@csehp3.mdc.com>
organization: The World Public Access UNIX, Brookline, MA
newsgroups: comp.lang.ada
Date: 1996-07-10T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <31E16C28.3BE2@csehp3.mdc.com>,
James A. Squire <m193884@CSEHP3.MDC.COM> 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.

- Bob