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.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: =?ISO-8859-1?Q?GNAT=A0and_Tasklets?= Date: Wed, 17 Dec 2014 22:31:57 +0200 Organization: Tidorum Ltd Message-ID: References: <455d0987-734a-4505-bb39-37bfd1a2cc6b@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net Wy/WKrvMnZEYBwCr3X06mg9ggINrllnJMwSjjuEZlwFsYVT40E Cancel-Lock: sha1:23ASPsKvuGvkdG/FiDrf4fp93rI= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:24074 Date: 2014-12-17T22:31:57+02:00 List-Id: On 14-12-17 15:06 , vincent.diemunsch@gmail.com wrote: > Hello Brad, > >> 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. > > I am rather surprised that you made a distinction between creating tasks > and parallelism. I agree that the goal of parallelism is to increase CPU > usage and therefore make the program run faster. For me creating tasks is > the Ada way of implementing parallelism. Ada uses tasks for parallelism, yes, but it is not the only purpose of Ada tasks. As Brad said, another purpose is to separate logical threads of control, and I would add a third purpose, which is to prioritize tasks of different urgencies, for real-time systems. >> 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. > > I could understand that a Library level task (i.e. a task declared immediately > in a package that is at lirary level) be mapped to an OS thread, but a > simple local task should definetly not. I disagree; I don't see any logical difference between a library-level task and a local task that would imply different implementations. That said, I might welcome a standard ability by which the programmer could suggest suitable implementations for specific tasks, for pragmatic reasons. Assuming, of course, that an Ada programming system (compiler + run-time support) provides more than one implementation of tasks. >> 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. >> [...] 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. > > The solution of all tasks under one kernel thread is good > for monoprocessors, As I remember, the user-level thread solution in GNAT had the drawback that if one thread blocked on an OS call, the whole program was blocked. > and since User Level threads are lightweight > compared to Kernel threads, My impression is that this is no longer the case, but perhaps things have changed again in recent years. > But with multiple cores, we need all tasks running on a pool of > kernel threads, one thread per core. In what way would that be better than having one kernel thread per task? In either case, each task would have to have its own stack area, and I don't see why task switching would be radically faster, either (assuming that these kernel threads share the same virtual memory space). > And I suppose that when multicores came, it has been considered > easier to drop the FSU implementation and simply map one task to > a kernel thread. My impression is that dropping the user thread model had more to do with improved kernel thread support in OSes and decreased kernel thread overheads compared to user threads. Of course, in proportion to the maintenance cost of the user-thread systems. The multi-core thing was probably a contributing factor, I agree. > But doing this is an oversimplification that > gives poor performances for pure parallel computing, and gave > rise to the need of parallelism Library ! I believe the parallelism library is there for the same reason as any other library: to implement reusable functionality, not specifically for fixing any problems in the Ada task system. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .