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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3834afba374f4cfd X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-05-04 23:27:18 PST Path: newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newshub2.home.com!news.home.com!news1.rdc1.sfba.home.com.POSTED!not-for-mail Message-ID: <3AF39D26.CD232953@home.com> From: Mark Biggar X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Requeue and IN OUT parameters References: <9cv3e9$gul$1@news.netmar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 05 May 2001 06:27:17 GMT NNTP-Posting-Host: 65.3.211.243 X-Complaints-To: abuse@home.net X-Trace: news1.rdc1.sfba.home.com 989044037 65.3.211.243 (Fri, 04 May 2001 23:27:17 PDT) NNTP-Posting-Date: Fri, 04 May 2001 23:27:17 PDT Organization: Excite@Home - The Leader in Broadband http://home.com/faster Xref: newsfeed.google.com comp.lang.ada:7195 Date: 2001-05-05T06:27:17+00:00 List-Id: 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