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,e8e240cec570cdf2 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-04-19 12:12:44 PST Newsgroups: comp.lang.ada From: Ted Dennison Sender: usenet@www.newsranger.com References: <9bkevj$61k$1@nh.pace.co.uk> <9bm76r$mf6$1@s1.read.news.oleane.net> <9bmuo9$50h$1@s1.read.news.oleane.net> Subject: Re: Multiple entry tasks Message-ID: Date: Thu, 19 Apr 2001 19:12:24 GMT NNTP-Posting-Host: 209.208.22.130 X-Complaints-To: abuse@newsranger.com X-Trace: www.newsranger.com 987707544 209.208.22.130 (Thu, 19 Apr 2001 15:12:24 EDT) NNTP-Posting-Date: Thu, 19 Apr 2001 15:12:24 EDT Organization: http://www.newsranger.com Path: supernews.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-out.uswest.net!news1.deniz.com!news.deniz.com!news-out.nuthinbutnews.com!propagator!feed2.newsfeeds.com!newsfeeds.com!newsranger.com!www.newsranger.com!not-for-mail Xref: supernews.google.com comp.lang.ada:7012 Date: 2001-04-19T19:12:24+00:00 List-Id: In article <9bmuo9$50h$1@s1.read.news.oleane.net>, Jean-Pierre Rosen says... > >The sequence of events I was thinking of is the following: >2) The call to Entry2 times out (it was a timed entry call). Ahhh. I didn't think about timed entry calls. Hmmm. So you are saying that the runtime can change the state of the entry queues between the start of a select statement and its decision to block or immediately accept an entry? In that case, an "abort"ed task would hose him as well, right? Generally I find that one has to be very carful about using timed or tenative entry calls. As a general rule, you have to be damn sure that the server will at some point sit and wait for your entry. If there's an "else" or "delay" clause on the server's selective wait, you can get into a nasty case of livelock. Since I generally need to use one of those clauses, I don't use timed or tenative rendezvous very much. Since I usually can't use them anyway, I don't think its much of a hardship to prohibit timed rendezvous (and aborts) for clients of this server. What you gain by doing this is an easier to maintain structure. With the way we did it, there are two select branches that must be maintined in lock-step for all but the highest-priority entry. That's not a big deal with our little toy example, as there was no code in any of the branches. But for a complicated server with loads of code in each branch, it could be a very big deal indeed. Then again, its possible you might want to do different things if the entry was accepted immediately vs. waited for. In that case what we did would be better. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com