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: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!feeder.erje.net!eu.feeder.erje.net!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: Sat, 25 Oct 2014 18:23:33 -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 1414275793 31698 192.74.137.71 (25 Oct 2014 22:23:13 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sat, 25 Oct 2014 22:23:13 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:TDuaUlX7D/tTXzX3XiQPymUQxns= Xref: news.eternal-september.org comp.lang.ada:22733 Date: 2014-10-25T18:23:33-04:00 List-Id: Jeffrey Carter writes: > I think the OP's problem is that he's trying to think about Ada tasking in terms > of message passing. Ada tasks operate with rendezvous and protected objects, > which are synchronous by default, rather than with message passing as in Erlang, > which is asynchronous by default. Right. If you want to think in terms of message passing, then you should think of a rendezvous as involving TWO messages. The entry caller sends a message to the callee, and then awaits a reply. When the callee reaches the accept, it receives the message, then does the stuff in the accept, then sends a reply message back to the caller. Then the caller wakes up and continues on its way. So the callee doesn't need to explicitly send a reply message back to the caller -- that happens automatically at the end of the accept. The callee doesn't know the identity of the caller. The caller needs to know the name of the callee, so it can call the entry. I prefer protected objects. Less coupling: two tasks can communicate with each other with neither one knowing the identity of the other -- they both just know about the protected object. If I were redesigning Ada from scratch, I'd leave out rendezvous. Everything you can do with rendezvous you can do with (something like) protected objects. - Bob