Re: GNAT and Tasklets

[Brad Moore <brad.moore@shaw.ca>]

On 2014-12-10 9:31 AM, vincent.diemunsch@gmail.com wrote:
> Hello,
>
> I have read some parts of the book from Alan BURNS « Concurrent and Real Time Programming in Ada ». He presents in chapter 11 an implementation of jobs that are submited to a pool of tasks (see : Callables, Executors, Futures). These jobs are typical of a parallel computation done on a multicore system, like computing a complex image, for instance.
>
> I find this really interesting and want to use this mecanism in the future, but it raises a question : if we use a library in Ada to do this tasking, we loose in fact the ability to use tasking directly inside the Ada langage ! And it is easy and cleaner to create a local task inside the subprogram for each job.

I dont think this is accurate, as creating tasks in Ada generally serves 
a different purpose than adding improved parallelism. Tasks are useful 
constructs for creating independent concurrent activities. It is a way 
of breaking an application into separate independent logical executions 
that separate concerns, improving the logic and understanding of a 
program. Parallelism on the other hand is only about making the program 
execute faster. If the parallelism does not do that, it fails to serve 
its purpose.

So the availability of a parallelism library shouldn't really affect the 
way one structures their program into a collection of tasks.

I find such a library is useful when one ones to improve the execution 
time of one/some of the tasks in the application where performance is 
not adequate. Tasks and parallelism libraries can complement each other 
to achieve the best of both worlds.


>
> So my question is : does GNAT create a kernel thread for each local task or is it able to compile local tasks as jobs sent to a pool of tasks created in the runtime ?

My understanding is that GNAT generally maps tasks to OS threads on a 
one to one basis, but as others have pointed out, there may be 
configurations where other mappings are also available.

My understanding also is that at one time, GNAT had an implementation 
built on top of FSU threads developed at Florida State University, by 
Ted Baker. This implementation ran all tasks under one OS thread. This 
highlights the difference between concurrency and parallelism. The FSU 
thread implementation gives you concurrency by allowing tasks to execute 
independently from each other, using some preemptive scheduling model to 
shift the processor between the multiple tasks of an application.

Using a parallelism library with a GNAT implementation based on FSU 
threads likely wont give you improved performance if all the tasks are 
executing concurrently within a single OS thread though, running on a 
single core of a multicore platform.

My understanding is that GNAT no longer supports this option to use FSU 
threads, mostly because there isn't sufficient customer interest in 
maintaining this. Or at least that is my recollection of what Robert 
Dewar stated in one of his emails a few years back.

Brad

>
> Kind regards,
>
> Vincent
>