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

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:1jlhu0mtzerde.1m8xbk8idroav$.dlg@40tude.net...
> On Wed, 7 Mar 2007 23:45:23 -0600, Randy Brukardt wrote:
...
> > A "declared parallel type" would be a private type that had a pragma
that
> > declared that all of it's operations were task-safe. (That's needed to
> > provide containers that could be used in parallel subprograms, for
> > instance.) Precisely what that would mean, I'll leave for some other
time.
> > (It would be possible to survive without this, as you could try to use
> > protected objects and interfaces for everything. That sounds like a pain
to
> > me...)
>
> That's the big question. Is task-safety a type property or one of the
> object?

For Ada, it's clearly of the type except for elementary types (for which you
can declare objects atomic).

> The fine-granularity approach presumes that task-safety could be
> hung on objects later on, i.e. sort of:
>
> declare parallel in parallel -- (:-))
>    I : Integer; -- Same as if it were declared atomic

I don't believe this statement; I don't see any reason that you couldn't use
the Ada approach with fine-grained parallelism.

> Since Ada 83 the language moved in the opposite direction, IMO. I suppose
> because there was no obvious way of making an unsafe ADT safe.

Right.

> The problem with the container types (and all other more or less
elaborated
> types) is that fine-granularity concurrency does not work for them. That
> was the reason of my original claim that PAR were worth of nothing without
> a feasible concept of synchronization somehow different from protected
> actions and rendezvous we have by now.

But it surely is possible to design ADTs that *do* work with fine-grained
(and heavy-grained!) parallelism. That requires some locking (I usually use
explicit locks, because I want to control the behavior in ways that
protected objects aren't good at. The locks are safe in that I always use
controlled locks that lock when initialized and unlock when finalized, so
that they don't get held forever if an exception or abort happens). I
certainly agree you can't add that sort of stuff later: it has to be baked
in right away - it's a critical part of the design.

And if you have parallel-safe ADTs, then fine-grained parallelism should
work, and it ought to be easier to program than traditional Ada tasks, as
there wouldn't be any explicit control flow interactions. So it seems
interesting to pursue...

                             Randy.