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,3f60acc31578c72b X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!tudelft.nl!txtfeed1.tudelft.nl!surfnet.nl!surfnet.nl!kanaga.switch.ch!irazu.switch.ch!news-zh.switch.ch!switch.ch!cernne03.cern.ch!cern.ch!news From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: question about tasks, multithreading and multi-cpu machines Date: Fri, 17 Mar 2006 15:23:37 +0100 Organization: CERN - European Laboratory for Particle Physics Message-ID: References: <1rz7na7qggm7p.1jcvc91svb4pd.dlg@40tude.net> NNTP-Posting-Host: abpc10883.cern.ch Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sunnews.cern.ch 1142605417 19139 (None) 137.138.37.241 X-Complaints-To: news@sunnews.cern.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060203 Red Hat/1.7.12-1.1.3.4 X-Accept-Language: en-us, en In-Reply-To: <1rz7na7qggm7p.1jcvc91svb4pd.dlg@40tude.net> Xref: g2news1.google.com comp.lang.ada:3401 Date: 2006-03-17T15:23:37+01:00 List-Id: Dmitry A. Kazakov wrote: > No. If you *know* that the application have to be executed on a > multi-processor machine then it is within the application domain. That's a valid point of view. > If you > don't or don't care, then it is an optimization issue. In which case someone somewhere needs to translate it into source code, unless you have very smart parallerizing compiler. I'm addressing the source code aspect of the whole. > 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 Yes, but accept and select are statements that operate with the concurrency that is already there. The problem is how to introduce this concurrency in the first place, without resorting to polluting the final solution with irrelevant entities. > 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? In the same way as you add something into each branch of the If statement. > Without code modification? So what about the If statement? :) Can you extend the branches of If without code modification? :| > Let I call some subprograms from each of the > execution paths, how could they communicate? Using objects that are dedicated for this, ehem, task. > What about safety? I don't see anything that would make it less safe than two separate task bodies. Take the code already presented by Jean-Pierre Rosen: declare task T1; task body T1 is begin A := 7; end T1; task T2; task body T2 is begin B := 8; end T2; begin null; end; My *equivalent* example would be: begin A := 7; with B := 8; end; (were's the Ada readability where you need it? ;) ) From the safety point of view, what makes my example worse than the one above it? What makes it less safe? > They would > definitely access some common data? Probably yes, probably not - depends on the actual problem to be solved. Let's say that yes, there is some shared data. What makes the data sharing more difficult/unsafe than in the case of two separate task bodies? > If they spin for a lock, then what was > the gain of concurrency? What is the gain of concurrency in the presence of locks with two separate task bodies? This issue is completely orthogonal to the way the concurrency is expressed. You have the same problems and the same solutions no matter what is the syntax used to introduce concurrency. > If they don't; how to maintain such sort of code > in a large complex system? The difference between separate task bodies and the support for concurrency on the level of control statement is that the former can be *always* built on top of the latter. The other way round is not true. > How can I rewrite it for n-processors (n is > unknown in advance)? With the help of asynchronous blocks, for example (I've mentioned about them in the article on my web page). As said above, more structured solutions can be always build on top of less structured ones. In particular, it would be quite straightforward to build a (generic?) package for this purpose, that would internally be implemented with the help of concurrent control structures - this is always possible. What I want is the possibility to express concurrency on the level that does not require me to use any new entity, if this new entity does not emerge by itself in the problem analysis. And the problem is that all popular languages (and libraries in the case of C++, for example) force me to work with entities which are irrelevant to the concept of concurrency itself. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/