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.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,e8e240cec570cdf2 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-04-19 07:42:50 PST Path: supernews.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeed.mesh.ad.jp!newsranger.com!www.newsranger.com!not-for-mail 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> Subject: Re: Multiple entry tasks Message-ID: Date: Thu, 19 Apr 2001 14:42:29 GMT NNTP-Posting-Host: 209.208.22.130 X-Complaints-To: abuse@newsranger.com X-Trace: www.newsranger.com 987691349 209.208.22.130 (Thu, 19 Apr 2001 10:42:29 EDT) NNTP-Posting-Date: Thu, 19 Apr 2001 10:42:29 EDT Organization: http://www.newsranger.com Xref: supernews.google.com comp.lang.ada:7002 Date: 2001-04-19T14:42:29+00:00 List-Id: In article <9bm76r$mf6$1@s1.read.news.oleane.net>, Jean-Pierre Rosen says... > > >"Marin David Condic" a �crit dans >le message news: 9bkevj$61k$1@nh.pace.co.uk... >> select >> when (Entry2'Count <= 0) and (Entry1'Count <= 0) => >> accept Entry3 ; >> when (Entry1'Count <= 0) => >> accept Entry2 ; >> or >> accept Entry1; >> else >> terminate; >> end select ; >> >This is wrong. Guards are evaluated only when the select is entered (unlike >POs), therefore if a task cancels its call (through timed entry call) while >the guards are being evaluated, you may end up in a situation of infinite >blocking. :-) I made the same misreading as you on my first post. The guards will only close if there is already an entry available on another branch. In that case the higher priority entry will be immediately accepted, so there will be no blocking at all. Thus there cannot be infinte blocking (execpt where intended :-) ). I think the confusing part was that he used "<= 0" rather than "= 0". 'count logically shouldn't ever go negative, but I guess he was trying to be safe (perhaps there's some degenerate case about that in the LRM. I'd check it if this were production code I was writing). I'd only expected to see a two-character boolean of ">= 0", so that's what my brain reported. :-( >select > accept Entry1; >else > select > accept Entry2; > else > select > accept Entry1; > or > accept Entry2; > or > accept Entry3; > or > terminate; > end select; > end select; >end select; > >1) Show that the sequence above exhibits a race condition >2) Show that the race condition is perfectly acceptable. Marin's code has the same "race condition". I also touched on that in a previous post, but I'm always happy to go into more detail. :-) Its quite possible for this server task to find no entries available and block down in the inner select (or in Marin's case, block with all the guards open). At that point, its quite possible for two separate tasks to become ready and enqueue on Entry1 and Entry2 before this server task becomes active again. At that point, the selection of which entry to accept will be based on factors other than the priority we have tried to set up. However, I would consider such "simultanious entries" to be a degenerate case which is really no worse than the case where the server task accepts Entry_3 8 CPU cycles before a client requests Entry_1. The duration of the inversion is practicly the same, and in both cases Entry_1 is still properly queued, and will take priority over any other Entry_2s and Entry_3s that arrive afterwards. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com