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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,1eef1e815cf70416 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.190.104 with SMTP id gp8mr2224165pbc.4.1339236000587; Sat, 09 Jun 2012 03:00:00 -0700 (PDT) Path: l9ni33211pbj.0!nntp.google.com!news2.google.com!goblin3!goblin1!goblin.stu.neva.ru!fdn.fr!feeder.news.orange.fr!not-for-mail Message-ID: <4FD31E9F.8030303@obry.net> Date: Sat, 09 Jun 2012 11:59:59 +0200 From: Pascal Obry Organization: Home - http://www.obry.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr-FR; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 Newsgroups: comp.lang.ada To: Maciej Sobczak Subject: Re: Distributed Systems Annex, data sharing between programs References: <8055acf5-188f-4b34-b4f0-83d70fee54f8@googlegroups.com> <96feb838-e0d3-4d06-abf0-79a8e74b5746@e20g2000vbm.googlegroups.com> <54af7ad7-7268-4d84-bafa-542e380a58f6@n16g2000vbn.googlegroups.com> <0d661453-423c-484b-90cd-4e80ffe1db5b@6g2000vbv.googlegroups.com> In-Reply-To: <0d661453-423c-484b-90cd-4e80ffe1db5b@6g2000vbv.googlegroups.com> NNTP-Posting-Date: 09 Jun 2012 11:59:59 CEST NNTP-Posting-Host: 90.23.18.69 X-Trace: 1339235999 reader.news.orange.fr 6165 90.23.18.69:10766 X-Complaints-To: abuse@orange.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Date: 2012-06-09T11:59:59+02:00 List-Id: Maciej, > The solution is to stop thinking in terms of RPC (remote procesure Right. > calls), and start thinking in terms of messages. If you lift the > concept of the message to the level of a design entity (yes, > distribution is *not* transparent and it *cannot* be an afterthought), > then some cool things are possible - just create thousands of messages > and let them go. No need to create additional tasks and no need to > wait for consecutive steps, as everything can happen in parallel > naturally. The original problem becomes feasible even in the presence > of partial failures, because separate message do not have to see their > delays and their individual communication problems. I don't agree, I've done that. One partition keeps a list of "job" (what you call message) in a protected object. package Job is pragma Remote_Types; type Object is tagged... package Job_Queue is pragma Remote_Call_Interface; function Get return Job.Object; ... And then each remote partition get a new job when needed. This ensure proper use of the resources as it naturally give good load balance. The speed of the remote machine or network is not an issue in this design. Again, I find Ada solution really good. The only point is that the Job above must be large grained ones. But this is true for every distributed applications where the cost of the network transfer must not negate the computing speed up. Also note that with the design above you don't need to go distributed only. You can also create some tasks on a single application to get multiple jobs on the same machine which is surely multicore, this also ease the debugging. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net - http://v2p.fr.eu.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver keys.gnupg.net --recv-key F949BD3B