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

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

On Fri, 9 Mar 2007 19:58:53 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:1jlhu0mtzerde.1m8xbk8idroav$.dlg@40tude.net...

>> 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.

Because it would not be magical! (:-)) In my understanding the idea of
fine-grained parallelism is similar to instruction pipelining. I don't need
to care about it when I write an Ada program. I define the constraints in
which the compiler/CPU may move (the language semantics) and let them
figure out the path they would go. If I had to care about it, that would
not be "fine" anymore.

>> 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.

Sure, the language must be self-consistent, so any forms of parallelism
must be mutually compatible.

> 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.

The problems with locks are:

1. Semaphores are low-level exposed to the danger deadlocks

2. Priority inversion issues

3. They rely on computationally heavy OS calls and resources

4. Controlled objects used to access locks are slow (OK, that's Ada
problem, it need not to be so, and can be fixed)

I think that for expressing "magical" parallelism one would inevitably need
some "magical" synchronization tools as well...

> 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...

Yes

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de