Re: RFC: Prototype for a user threading library in Ada

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

Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:nkinr0$1h8t$1@gioia.aioe.org...
> On 24/06/2016 00:12, Randy Brukardt wrote:
>
>> That wasn't my question; I'm wondering the motivation for these features 
>> in
>> terms of parallelization.
>
> Because fine-grained (tightly coupled) parallelism is dead on arrival if 
> you use synchronous exchange. You cannot wait for a response without 
> imposing huge accumulating latencies.

Parallelism, in general, is DOA if you need any significant exchange at all. 
As you say, that makes the effort effectively sequential. The cases where it 
works tend to use order-independent accumlators and fairly large chunks of 
accumulation.

>> In today's world, it's impossible to consider any
>> feature in a purely sequential manner. The expressiveness gain (if any) 
>> is
>> secondary. And the OP was talking about parallelism, not generators.
>
> Of course you can. Nobody is capable to write anything more or less large 
> in a data event-controlled way. All logic of exchanges between parties is 
> always strictly sequential: you compute, publish data, get subscribed 
> data, compute again.

Right. If there's a lot of exchange, it's not a candidate for parallelism.

>> The generator proposal as expressed in AI12-0197-1 is just too expensive 
>> to
>> consider for a purely sequential feature.
>
> I don't see much use in the proposal. The key feature must be the points 
> where the "task" yields control, enters non-busy wait for an external 
> event. Ideally it must be shaped as an accept statement or an entry call.

Jean-Pierre Rosen proposed a ""passive task" feature as an alternative to 
the generator proposal. It uses the existing task syntax, but gets rid of 
the thread of control.

Of course, Janus/Ada implements all tasks that way today, so I don't see a 
lot of benefit to that. But I can see where it might help other 
implementations.

>> For Janus/Ada on Windows, we'd
>> either have to throw away 1/3 of the back-end of the compiler (and 
>> generally
>> use slower instructions in some cases, impacting all code), or implement
>> these *exactly* as we do tasks (with a TCB, context switching, and so 
>> on).
>> [Not to mention the extensive changes needed to the front-end.] For
>> something to be worth that sort of effort, it has to benefit a large
>> percentage of programs. This (as a purely sequential feature) doesn't do
>> that.
>
> I don't understand the point. All tasks are sequential. That didn't 
> prevent them being used in parallel computing.

The feature as proposed can't be used in a task unless one (manually) adds 
locking, meaning you still have all of the possibilities for deadlock and 
race conditions. I believe that if we're going to advance parallelism at 
all, we have to do something to make it possible to write (sufficiently 
restricted and compile-time checked) code where one doesn't need to worry 
about those things. After all, the main reason that it's too hard to write 
parallel code is the need to carefully consider every possible deadlock and 
race condition. Otherwise, something like Parafin would provide everything 
needed and Ada clearly would be the choice for parallel code. ;-)

So I don't see any reason to add any new sequential features that add to, 
rather than reduce, the possibilities of deadlock and races. Certainly not 
if they take a lot of effort to implement, and don't seem to have general 
utility.

                                           Randy.