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 X-Google-Thread: 103376,3f60acc31578c72b X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: question about tasks, multithreading and multi-cpu machines Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: Date: Fri, 17 Mar 2006 12:36:10 +0100 Message-ID: <1rz7na7qggm7p.1jcvc91svb4pd.dlg@40tude.net> NNTP-Posting-Date: 17 Mar 2006 12:36:10 MET NNTP-Posting-Host: afcdfdc8.newsread4.arcor-online.net X-Trace: DXC=cZFmHdVf^U^H^J66Eo??P_:ejgIfPPldTjW\KbG]kaMXeDdmR4DE3R\8oD:Y^R::_VWRXZ37ga[7Zn919Q4_`VjYNZZj5LgkU On Fri, 17 Mar 2006 09:22:21 +0100, Maciej Sobczak wrote: > Consider a simple example of two long vectors that need to be added. In > the simplest case you do this: > > for I in Vector'Range loop > V3(I) := V1(I) + V2(I); > end loop; > > and you're done. > > Now, assume that you want to target dual-CPU machine and you *know* that > you could greatly benefit from making things in paraller. > > Do you see any need to model the above sentence using additional objects? > I don't, because in the *application domain* no additional type nor > object was created by just computing things in paraller. No. If you *know* that the application have to be executed on a multi-processor machine then it is within the application domain. If you don't or don't care, then it is an optimization issue. So if it is the domain, then you should invest a little bit more into careful design, and consider performance issue on 1, 2, n-processors machines. So concurrency will be a sufficient part of the design. > That's why the "lightweight concurrency", like in Occam, would be more > appropriate here. Something like this: > > declare > procedure Add_Range(First, Last : in Index_Range) is > begin > for I in First .. Last loop > V3(I) := V1(I) + V2(I); > end loop; > end Add_Range; > begin > Add_Range(Vector'First, Vector'Last / 2); > with > Add_Range(Vector'Last / 2 + 1, Vector'Last); > end; > > (syntax taken from the top of my head) I don't think that Occam's style of concurrency could be an viable alternative. Mapping concurrency onto control flow statements is OK, and Ada has this as accept and select statements [AFAIK, Occam was one of Ada's precursors.] But the real problem is that it isn't scalable and composable. The code like above is very difficult to reuse. Let you want to extend it. How can you add something into each of two execution paths? Without code modification? Let I call some subprograms from each of the execution paths, how could they communicate? What about safety? They would definitely access some common data? If they spin for a lock, then what was the gain of concurrency? If they don't; how to maintain such sort of code in a large complex system? How can I rewrite it for n-processors (n is unknown in advance)? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de