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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.237.36.4 with SMTP id r4mr25025809qtc.30.1467531777387; Sun, 03 Jul 2016 00:42:57 -0700 (PDT) X-Received: by 10.157.47.177 with SMTP id r46mr1117006otb.15.1467531777345; Sun, 03 Jul 2016 00:42:57 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!f89no1760409qtd.0!news-out.google.com!o189ni387ith.0!nntp.google.com!r1no9648988ige.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 3 Jul 2016 00:42:57 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=78.192.88.225; posting-account=21X1fwoAAABfSGdxRzzAXr3Ux_KE3tHr NNTP-Posting-Host: 78.192.88.225 References: <58b78af5-28d8-4029-8804-598b2b63013c@googlegroups.com> <1e32c714-34cf-4828-81fc-6b7fd77e4532@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <2598edcf-b0fd-4ceb-b1c4-8930371dd3cb@googlegroups.com> Subject: Re: RFC: Prototype for a user threading library in Ada From: Hadrien Grasland Injection-Date: Sun, 03 Jul 2016 07:42:57 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 5001 X-Received-Body-CRC: 3765585780 Xref: news.eternal-september.org comp.lang.ada:31012 Date: 2016-07-03T00:42:57-07:00 List-Id: Le samedi 2 juillet 2016 23:14:30 UTC+2, Niklas Holsti a =C3=A9crit=C2=A0: > On 16-07-02 14:13 , Hadrien Grasland wrote: > > Le samedi 2 juillet 2016 06:36:09 UTC+2, Randy Brukardt a =C3=A9crit : > >> But I don't think that really helps the race and deadlock issues > >> that are the real problem with programming with Ada tasks. I'd like > >> to find some help there, too. > > > > Here's my view of this: people are heavily overusing shared mutable > > data in multitasking programs, and that is the source of too many > > data races, which in turn people attempt to fix with locks, thusly > > killing their performance and introducing deadlocks. > > > > In many cases, better performance and correctness can be easily > > achieved by moving to asynchronous tasking runtimes, where the > > runtime internally manages an event-based dependency graph of tasks > > that can be processed condurrently, and data is kept task-private but > > can be moved around between tasks. >=20 > Do you have real experience of such "asynchronous tasking runtimes"? In= =20 > Ada or in other languages? I have quite a bit of experience with OpenCL and HPX. OpenCL is based on ra= w events, while HPX adds some nice syntaxic sugar for moving data across ta= sks in the form of futures. OpenCL is an API that was designed for offloading parallel computations to = pretty much every kind of programmable hardware, so its designers had to pa= y quite a bit of attention to IO latency concerns when designing it, which = naturally led them to embrace an asynchronous tasking model. Whereas if you= are familiar with the C++11 std::async construct, HPX is essentially that = programming model on steroids (more limited in hardware scope than OpenCL, = but more pleasant to use). As for languages, OpenCL is a C API, though I ended up writing a C++ wrappe= r fairly quickly because the C constructs were hurting my eyes too much. HP= X is a C++ API. I am not aware of any similar similar work in Ada, so since= I really like this programming model, I thought I would give it a shot. > It seems to me that it would be difficult for such a run-time system to= =20 > support the full Ada tasking features, such as conditional entry calls.= =20 > Ada tasks have more control over their own execution than such a=20 > run-time system would allow. Yes, to support the full Ada tasking feature set would likely entail gettin= g support from compiler implementors, see the lengthy discussion on corouti= nes above for an example :) =20 > Moreover, in present Ada it seems to me that the only way to move=20 > task-private data from one task to another is to send a copy of the data= =20 > from one task to the other. Copying data is often poison for performance. Cheaply moving data around is possible in any language that has heap alloca= tion and pointers. What is more difficult is to provide an easy to use synt= ax around it. > Perhaps a new, restricted tasking profile would be needed, analogous to= =20 > the Ravenscar profile but aimed not at real-time systems but at parallel= =20 > computation in this event-based style. It is true that for computation purposes, the full Ada tasking model may al= so be overkill. For example, asynchronous transfer of control can be hard t= o support, and is often overkill for compute scenarios.