Re: Requeue and IN OUT parameters

[Mark Biggar <mark.a.biggar@home.com>]

adam@irvine.com wrote:
> 
> I have a couple more questions about protected objects.  Here's the first
> question; the second will be in a separate post.
> 
> 9.5.4(11) says that if an entry body completes other than by a
> requeue, the program returns to the caller and any copy-back of
> parameters occurs.  What happens to the parameters if the entry
> body does a requeue?

If an entry body ends with a requeue the as far as the caller is
concerned the entry call isn't finished yet, so no copy back
should happen yet. 

> In this example:
> 
>     protected PR is
>        entry E1 (Count : in out integer);
>        entry E2 (Count : in out integer);
>     end PR;
> 
>     protected body PR is
>        entry E1 (Count : in out integer) when Some_Condition is
>        begin
>            if Blah_Blah_Blah then
>                Count := Count + 1;
>                requeue E2;
>            end if;
>            Do_A_Bunch_Of_Other_Stuff;
>        end E1;
>     . . .
> 
> In this example, does the effect of the statement "Count := Count + 1"
> become lost?  Is the value E2 sees the original value of Count, the
> incremented value, or implementation-dependent?

It is implementation dependent whether "in-out" parameters are
implemented using copy-result or by-reference.  So, it appears
to be implementation defined whether or not the modification to 
Count is lost.  Thus the above code is non-portable.  Now some types
are by definition by-reference (limited, tagged, etc.) and for
these types the above is portable and the modification would 
survive.  Thus to make your example portable you could wrap
Count inside a limited record type and force portable behavior.

Note, one possible surprising implication of this is that if a timed
entry call with by-refernece in-out parameters times out there is
no guarantee that those parameters have not been modified.

--
Mark Biggar
mark.a.biggar@home.com