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
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!weretis.net!feeder4.news.weretis.net!newsfeed.tele2net.at!news.panservice.it!feed.xsnews.nl!border01.ams.xsnews.nl!feeder01.ams.xsnews.nl!frontend-F06-15.ams.94.232.116.90
Date: Sun, 26 Oct 2014 16:53:16 +0000
From: Martyn Pike <usenet@embeddedconsultinguk.com>
Reply-To: usenet@embeddedconsultinguk.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Example question
References: <0fbd755d-7bcf-42b1-a20b-c6a2c74c7d6e@googlegroups.com>
 <544d02cc$0$14840$c00b7f07@94.232.116.90> <m2j529$o1b$1@dont-email.me>
In-Reply-To: <m2j529$o1b$1@dont-email.me>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <544d26ff$0$14265$c00b7f07@94.232.116.90>
Organization: usenetbucket
Xref: news.eternal-september.org comp.lang.ada:22763
Date: 2014-10-26T16:53:16+00:00
List-Id: <comp.lang.ada>

On 26/10/2014 15:46, J-P. Rosen wrote:
> Le 26/10/2014 15:18, Martyn Pike a écrit :
>>> Tutorial says "If calls to both entries are already pending, one will
>>> be accepted non-deterministically." what does that mean? If calls are
>>> pending on bith entries it might happend that Shutdown is accepted and
>>> exits in which case thats not good solution at all
>>>
>>>
>>
>> It basically means exactly what you said.  If calls are pending on both
>> entries then it is not deterministic as to which one will be processed
>> first.
> No. "one of them is selected according to the entry queuing policy in
> effect" (9.7.1(16))
>
> It was never non deterministic. Implementation defined in previous
> versions of the language.
>

Ok - the order cannot be assumed or ascertained by the order of the 
select statements in the source code.  I think that's what the OP is 
questioning.

>> If you want deterministic behaviour then in my opinion this is where
>> protected objects should be used.  Particularly if you absolutely must
>> check for the existence of a Shutdown event before checking for a
>> Recalculate event.
> If you tell what kind of deterministic behaviour you want, it is easy to
> write the expected behaviour with rendezvous.
>

Agreed it may be easy but my personal preference is to use protected 
objects.