Re: question about tasks, multithreading and multi-cpu machines

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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