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

["Randy Brukardt" <randy@rrsoftware.com>]

"Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> wrote in message
news:pan.2007.03.06.02.02.27.892793@linuxchip.demon.co.uk.uk.uk...
...
> PAR is about indicating in the source code which statement sequences
> are unordered.  The idea is to make the syntax for concurrency
> as simple as the syntax for sequentality. Perhaps using "par"
> instead of "begin" is the way to go.  Adding "all" to the for
> loop also makes a lot of sense.

My $0.02 worth:

One thing I'm absolutely certain of is that "par" would never, ever appear
in Ada. That's because Ada keywords are always complete English words
(that's true in the packages, too; abbreviations are frowned upon). I admit
that "par" *is* an English word, but it doesn't have anything to do with
parallel. So, I think the syntax would be more likely something like "begin
in parallel" or the like. (Similarly, "all" in a for loop is just too small
a keywork for such a major semantic change. I think I'd prefer "parallel" to
be used somewhere in the loop syntax; but I could be proved wrong in this
instance.)

> If you can persuade programmers to use "par" unless they explicitly
> *need* sequential execution, a great many statements will be marked
> as concurrent.  Numeric codes will use "par" in the computational
> core, as well as outer layers of execution.

Yes, and a great number of programs will have become unstable. That's
because the default in Ada is for objects that are *not* safe to access in
parallel. (That's a problem for Ada tasks, too.) Only objects with pragma
Atomic and objects wrapped in protected objects can be assumed safe.

I know you've said that you would expect programmers to worry about such
things. But that's the C way of thinking about things, and that is the root
of much of the unreliably of modern software. Programmers are likely to test
their programs on some compiler and then assume that they are correct. But
when dealing with parallel execution, nothing could be further from the
truth. The next compiler or OS will make the program execute completely
differently. The only way to "test" these things is to have tools that
enforce proper behavior (no access to global objects without
synchronization, for instance).

Of course, there is no problem with purely independent subprograms. The
problem is that hardly anything is purely independent, even most independent
algorithms depend on shared data (like a database) to guide their execution,
and if something else is changing that data, there is a lot of potential for
trouble.

...
> Mandating sequential execution except where the "pragma" is used
> puts parallel statements at an immediate disadvantage - it makes
> them seem to be second class citizens, added on afterwards
> in an attempt to speed things up. Par should be "everywhere", it's
> a *basic* component of program semantics - like a loop or a function call.
> It's absent from programming languages is because processors can't really
> take advantage of it at present, and text is inherently linear, needing no
> special "seq" directive.  Graphical languages on the other hand often
> imply concurrency automatically, and so have the opposite property. "par"
> is not a hint.
>
> Enough ranting for now...

Darn, you were just getting interesting. ;-)

$0.02 cents. Ada has the needed building blocks for parallel execution,
given that it has defined what is and is not accessible in parallel. Most
other programming languages have never thought of that, or found it too
hard, or just don't care. But you also need enforcement of safe access to
global objects (global here means anything outside of the subprograms that
were called in parallel). I don't think that that would be very practical in
Ada; the result would be pretty incompatible. (Maybe you could have
procedures defined to allow parallel execution, sort of like a pure
function, but it sounds messy. And we've never had the will to properly
define Pure functions, either, that's because we couldn't decide between the
"declared Pure and user beware" and "defined and checked Pure" approaches).

What really would make sense would be a meta-compiler, that took source code
in an Ada-like language with "begin in parallel" and other needed constructs
and converted that to regular Ada code. (Parallel calls would turn into
tasks, appropriate checking would occur, etc.). But the majority of the code
would simply get rewritten into Ada - and then an Ada compiler could compile
it. Such a system would be free of Ada compatibility concerns, but wouldn't
necessarily have to give up much of Ada's power. (And, if it caught on, the
Ada step could be dropped completely.) Clearly, the meta-compiler would have
to know something about the target (how many threads are reasonable, for
instance), but not necessarily a lot. Such a system could be a lot safer
than Ada is (well, at least until you have to make a call to C...),
especially for parallel execution.

                             Randy Brukardt.