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

[Maciej Sobczak <no.spam@no.spam.com>]

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/