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

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

On 2016-06-25 01:00, Randy Brukardt wrote:
> 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.

It is an oversimplification. There is a large area in between where it 
works. Look how multi-core architectures blossom. A multi-core is a kind 
of parallelism with far greater exchange rate and coupling (all shared 
memory) than an architecture of piped communications.

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

And this is exactly what is needed, IMO. A set of "tasks" driven by 
another task, switched in a non-preemptive manner.

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

Only losses for blocking I/O.

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

The problem at hand is that parallel asynchronous code cannot be 
designed in a reasonable way, at all. It is written it in a form of a 
state machine, logically and technically *gotos*. It is the state of 
software engineering of 70s wrapped in Ada constructs.

Before we can talk about deadlocks, which I am almost sure impossible to 
statically eliminate in this case, we need to be able to design the 
software in a minimally sane way.

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

You cannot reduce them, they are in the nature of exchange protocols, 
application logic, physically distributed hardware and software. Each 
time you get a timeout running some networking application, that because 
of some deadlock somewhere.


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