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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: buffer1.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!news.stack.nl!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Simp,e example for 2 tasks Date: Mon, 22 Sep 2014 21:27:02 +0200 Organization: cbb software GmbH Message-ID: References: <9b22dd09-6137-4f4b-8be1-28255032df70@googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: ZB2Fb2q1fa4xpMpNKFqV6Q.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: number.nntp.dca.giganews.com comp.lang.ada:189091 Date: 2014-09-22T21:27:02+02:00 List-Id: On Mon, 22 Sep 2014 21:16:14 +0300, Niklas Holsti wrote: > On 14-09-22 20:48 , Jeffrey Carter wrote: >> On 09/22/2014 12:18 AM, Niklas Holsti wrote: >>> >>> Hmm... I don't quite agree with that. It seems to me that rendez-vous >>> interaction between tasks could be implemented in a distributed system, >>> as long as the entry parameters can be passed by value or by copy-in >>> copy-out. It is the global shared variables and reference parameters >>> that would make a distributed approach difficult for Ada programs using >>> such constructs. I don't know Erlang well enough to understand if it has >>> some solution for that, or if it simply forbids such things. >> >> Well, of course one can implement rendezvous between tasks in different >> partitions in a distributed system, since that's possible through the DSA. > > I meant, rather, that an Ada RTS could have implemented distributed > rendez-vous without (and before) the DSA -- that the mere fact that > rendez-vous is synchronous does not mean that it cannot be distributed. Which can and is. Another name for it is RPC. > I'd bet that most distributed systems today communicate through > synchronously used, bidirectional, TCP request-reply streams, not > through asynchronous message-passing with long queues. But I include > web-based applications as distributed systems. Synchronous calls are much easier to use program. They become less expensive with more cores. Asynchronous messaging in this context make no sense at all. Provided under messaging we understand a request-response schema. Buffering does not improve latencies when a positive acknowledge or other response is required. IMO, the real use case for asynchronous communication is one directional exchange, e.g. data and event distribution without positive acknowledging. Specifically, publisher/subscriber schemas with avoiding priority inversion or blocking the publisher etc. This is where asynchronous communication really shines. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de