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.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no 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-18 13:35:55 PST Path: supernews.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!194.176.220.130!newsfeed.icl.net!isdnet!psinet-france!psiuk-f4!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Multiple entry tasks Date: Wed, 18 Apr 2001 16:16:24 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9bksmp$ang$1@nh.pace.co.uk> References: <9bkevj$61k$1@nh.pace.co.uk> <8slD6.1888$D4.184457@www.newsranger.com> NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 987624985 10992 136.170.200.133 (18 Apr 2001 20:16:25 GMT) X-Complaints-To: newsmaster@pace.co.uk NNTP-Posting-Date: 18 Apr 2001 20:16:25 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: supernews.google.com comp.lang.ada:6985 Date: 2001-04-18T20:16:25+00:00 List-Id: If multiple rendezvous become active before you hit the select, I'd imagine that they would have to be queued according to the priority of the tasks that called the entries. It is a marginal case but probably worth thinking about for a minute anyway... If two tasks of the same priority were calling, say, Entry2 - then its a coin toss as to which gets there first. If two tasks of the same priority were calling different entries, then the priority of the entry would decide which got to run. If two tasks of different priority call the same entry, then the higher priority task gets it. If two tasks of different priorities call different entries, then you might get a priority inversion - if both Entry2 and Entry3 have callers, then Entry3 is blocked when you get to evaluating it.So even if the task calling Entry3 is of higher priority, it gets blocked until Entry2 finishes. So there's only one case that is ill-defined - except that in a single processor environment, one of them would have to have arrived there first. In a multiple-processor environment, one starts to imagine true simultaneous arrival - which I guess is going to get somehow arbitrated by the hardware. (Unless the Indivisible Instruction finally meets the Unmaskable Interrupt! :-) You'll probably at least have a deterministic answer - if not the answer you wanted. Some other mechanism needs to decide the same-priority-same-entry case. The priority inversion is a consequence of entry priority having preference over task priority. Presumably, you're design needed to consider that when you dreamed up the notion of prioritizing the entries. (I think that case is in the ARM under the "I Weep For You!" rule of task design. ;-) Truly an interesting state of affairs, eh? MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Ted Dennison" wrote in message news:8slD6.1888$D4.184457@www.newsranger.com... > In article , Ted Dennison says... > Doh! I misread the conditionals. If waiting occurs, all the guards will be > *open*. That should work fine (assuming the "or" is added, of course). If > multiple rendezvous become active before this task gets around to accepting one, > I suppose the priority principle could be violated. But that's a pretty marginal > case.