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=unavailable autolearn_force=no version=3.4.4 Path: border1.nntp.dca3.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.netfront.net!not-for-mail From: "Jeffrey R. Carter" Newsgroups: comp.lang.ada Subject: Re: Ada advocacy Date: Fri, 30 Aug 2013 17:02:38 -0700 Organization: Netfront http://www.netfront.net/ Message-ID: References: <19595886.4450.1332248078686.JavaMail.geo-discussion-forums@vbbfy7> <2012032020582259520-rblove@airmailnet> <12ee9bc5-3bdf-4ac0-b805-5f10b3859ff4@googlegroups.com> <6c58fae4-6c34-4d7a-ab71-e857e55897c0@x6g2000vbj.googlegroups.com> NNTP-Posting-Host: 162.72.49.19 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: adenine.netfront.net 1377907362 89788 162.72.49.19 (31 Aug 2013 00:02:42 GMT) X-Complaints-To: news@netfront.net NNTP-Posting-Date: Sat, 31 Aug 2013 00:02:42 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 In-Reply-To: X-Original-Bytes: 2704 Xref: number.nntp.dca.giganews.com comp.lang.ada:183234 Date: 2013-08-30T17:02:38-07:00 List-Id: On 08/30/2013 03:41 PM, Robert A Duff wrote: > > > In the rendezvous case, the task doing the conditional entry call is > quite likely to take LONGER (in real time) to notice that the entry is > not open (than in the protected object case). And therefore longer to > jump to the 'else' part. I have implemented this stuff, and I know what > goes on behind the scenes -- there's (hidden) locking in the rendezvous > case, too, and yes that means that it can take some time to decide to > jump to the 'else'. That's surprising to learn, and useful to know. The ARM-83 used the called task's place in its execution, as I recall: if the called task was at an accept for the called entry, or at a select with an open alternative for the called entry, then the rendezvous took place; otherwise, the calling task took the else part. ARM-95 changed that to whether the call was queued: if the call was queued at any point, the call is canceled and the caller takes the else part; otherwise the caller remains in the select part. -- Jeff Carter "Now go away or I shall taunt you a second time." Monty Python and the Holy Grail --- news://freenews.netfront.net/ - complaints: news@netfront.net ---