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.dca1.giganews.com!nntp.giganews.com!news.glorb.com!feed.news.qwest.net!mpls-nntp-02.inet.qwest.net!132.250.1.121.MISMATCH!ra.nrl.navy.mil!bloom-beacon.mit.edu!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!.POSTED!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: confusion about message passing between the tasks Date: Sun, 26 Oct 2014 20:46:57 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls7.std.com 1414370798 8541 192.74.137.71 (27 Oct 2014 00:46:38 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Mon, 27 Oct 2014 00:46:38 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:G+uGf3RVGi94T6F+Eg4TrxJaznU= Xref: number.nntp.giganews.com comp.lang.ada:190103 Date: 2014-10-26T20:46:57-04:00 List-Id: Jeffrey Carter writes: > I'm pretty sure entry bodies use "is", not "do". Sorry. Obviously I didn't compile my code. ;-) > I think so. > > task T is > pragma Passive; > > entry Entry_1; > entry Entry_2; > end T; > > task body T is > State : State_Enum := Accepting_Entry_1; > begin -- T > loop > select when State = Accepting_Entry_1 => > accept Entry_1 do > ... > if ... then > State := Accepting_Entry_2; > end if; > end Entry_1; > or when State = Accepting_Entry_2 => > accept Entry_2 do > ... > if ... then > State := Accepting_Entry_1; > end if; > end Entry_2; > or > terminate; > end select; > end loop; > end T; I think that has slightly different semantics. For example: select T.Entry_1(...); else ... end select; In the PO case, we know that if Entry_1 was not acceptable, then Entry_2 must be (at that time). In the "select/accept" case, there is a moment in time when neither entry is acceptable (when T is going around that loop, jumping back to the "select"). That might seem like a nitpick, but imagine the thing (PO or task) alternates between the two states, and clients depend on that fact. In the passive-task case, we have this weird in-between state in which neither entry is open. And that's unlikely to be caught by testing, because it's rare. In the PO case, we know for sure that if the above conditional entry call finds Entry_1 closed, then Entry_2 must be open (at that time). OTOH, perhaps you mean that "pragma Passive_Task" should change the semantics of loop statements containing selects (and nothing else) such that that window doesn't happen. That could work, I suppose, but it means that the pragma is not just an optimization, but has a subtle semantic effect. I'm not sure how to even write RM wording to capture that. My first experience with a high-level language supporting concurrency (as opposed to rolling-your-own in assembly, or via OS calls) was Per-Brinch Hansen's Concurrent Pascal. Processes (like Ada tasks) and monitors (like Ada PO's, except PO entries crucially have barriers). When I learned Ada 83, it struck me as weird that you have to write write a task with a loop and a select-with-terminate to do what a monitor does (it doesn't DO anything, but simply waits to be told what to do). - Bob