Re: Broadcast / iterate to all Connection objects via Simple Components?

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 2023-02-19 3:27, A.J. wrote:


> Creating a task in Ada, at least on linux, ends up creating a
> pthread,

With the current GNAT compiler, yes. But not necessarily with all Ada 
compilers, even on Linux.


> coroutines are managed by the go runtime (I believe in user space) 
> and have much less overhead to create or manage, since it's not
> creating a specific thread.

Some Ada compilers may have run-times that implement Ada tasks within 
the run-time, with minimal or no kernel/OS interaction.


> Ada 202x supports the "parallel" block[3] though I understand no 
> runtime has utilized it yet-- would that end up being a coroutine or
>  is it meant for something else?
> 
> [3] http://www.ada-auth.org/standards/22rm/html/RM-5-6-1.html

As I understand it, the parallel execution constructs (parallel blocks 
and parallel loops) in Ada 2022 are meant to parallelize computations 
using multiple cores -- that is, real parallelism, not just concurrency.

The Ada2022 RM describes each parallel computation in such a parallel 
construct as its own thread of control, but all operating within the 
same task, and all meant to be /independent/ of each other. For example, 
a computation on a vector that divides the vector into non-overlapping 
chunks and allocates one core to each chunk.

Within a parallel construct (in any of the parallel threads) it is a 
bounded error to invoke an operation that is potentially blocking. So 
the independent computations are not expected to suspend themselves, 
thus they are not co-routines.

The parallelism in parallel blocks and parallel loops is a "fork-join" 
parallelism. In other words, when the block or loop is entered all the 
parallel threads are created, and all those threads are destroyed when 
the block or loop is exited.

So they are independent threads running "in" the same task, as Dmitry 
wants, but they are not scheduled by that task in any sense. The task 
"splits" into these separate threads, and only these, until the end of 
the parallel construct.

Moreover, there are rules and checks on data-flow between the 
independent computations, meant to exclude data races. So it is not 
intended that the parallel computations (within the same parallel 
construct) should form pipes or have other inter-computation data flows.