From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!fx08.iad.POSTED!not-for-mail From: Brad Moore User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: =?ISO-8859-1?Q?GNAT=A0and_Tasklets?= References: <455d0987-734a-4505-bb39-37bfd1a2cc6b@googlegroups.com> In-Reply-To: <455d0987-734a-4505-bb39-37bfd1a2cc6b@googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Message-ID: NNTP-Posting-Host: 68.145.219.148 X-Complaints-To: internet.abuse@sjrb.ca X-Trace: 1418704951 68.145.219.148 (Tue, 16 Dec 2014 04:42:31 UTC) NNTP-Posting-Date: Tue, 16 Dec 2014 04:42:31 UTC Date: Mon, 15 Dec 2014 21:42:32 -0700 X-Received-Bytes: 3964 X-Received-Body-CRC: 2280568046 Xref: news.eternal-september.org comp.lang.ada:24030 Date: 2014-12-15T21:42:32-07:00 List-Id: 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 >