Re: PAR (Was: Embedded languages based on early Ada)

[Ray Blaak <rAYblaaK@STRIPCAPStelus.net>]

"Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> writes:
> Concurrency involving independent operating units without communication is
> often straightfoward.  There is no communication to screw up - data are read
> in parallel and combined serially.  This a very common and useful type.

Well, sure. It really depends on the nature of what is being computed.

My position of treating parallel programming as something that is painful
comes about from dealing with concurrent items that do interact with each
other. It can get quite difficult to reason that things are correct, that
deadlocks and livelocks are avoided, etc.

> In my opinion, "par" and "seq" were technically successful in Occam,
> and many of the difficult and subtle problems are absent from the
> above code because the concurrent units *cannot* address each other.
> These parallel constructs are simpler and more restricted than Ada
> tasks.  The point of "par" is that the restrictions eliminate concerns
> over control flow.  The issue is checking for erroneous data flow
> (eg accidental concurrent updates).  The compiler should warn when
> this appears to be a hazard.

Occam looked fun. I don't think its simplicity would work in Ada, however.

But that is not the real point. Adding constructs like "parallel" that make
concurrency easier to express in Ada is a good idea. Programmers are free to
try and learn how to use them properly.

It then becomes a algorithm design and code review issue, rather than a
language issue, as to whether the choice of sequential vs parallel was
appropriate in any given situation.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.