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.200.37.170 with SMTP id e39mr27817371qte.20.1467580511574; Sun, 03 Jul 2016 14:15:11 -0700 (PDT) X-Received: by 10.157.10.85 with SMTP id 79mr176661otg.12.1467580511528; Sun, 03 Jul 2016 14:15:11 -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!news.glorb.com!f89no1949670qtd.0!news-out.google.com!o189ni1048ith.0!nntp.google.com!r1no10177072ige.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 3 Jul 2016 14:15:11 -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> <2598edcf-b0fd-4ceb-b1c4-8930371dd3cb@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: RFC: Prototype for a user threading library in Ada From: Hadrien Grasland Injection-Date: Sun, 03 Jul 2016 21:15:11 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:31017 Date: 2016-07-03T14:15:11-07:00 List-Id: Le dimanche 3 juillet 2016 10:39:48 UTC+2, Dmitry A. Kazakov a =C3=A9crit= =C2=A0: > On 2016-07-03 09:42, Hadrien Grasland wrote: > > Le samedi 2 juillet 2016 23:14:30 UTC+2, Niklas Holsti a =C3=A9crit : >=20 > >> Moreover, in present Ada it seems to me that the only way to move > >> task-private data from one task to another is to send a copy of the da= ta > >> from one task to the other. Copying data is often poison for performan= ce. > > > > Cheaply moving data around is possible in any language that has heap > > allocation and pointers. >=20 > That is the most expensive way doing it, and on top of that, it requires= =20 > shared memory (pool) and thus process-global interlocking. You arrived=20 > at the starting point. Please define what you mean by expensive. Whenever the hardware architectur= e allows for it, passing a pointer to a heap-allocated data block is almost= always faster than deep-copying that data from one thread-private area of = memory to another, as long as the data is large enough. =20 > BTW, when talking about asynchronous model, marshaling must be=20 > asynchronous too. Another drawback of the method of doing that through=20 > pointers is that it must be atomic =3D synchronous =3D> you could not dea= l=20 > with large objects, on-demand production models etc. And this is where=20 > event-controlled model stop working, as it separates data from=20 > data-related events. A proper abstraction must combine everything into=20 > ADT objects. Indeed, I also agree that when an event is used to notify a listener that s= ome piece of data has been produced, it is almost always better to combine = together the event and the data block being produced in a single abstractio= n, a future. However, futures are less general than events. In runtimes that only have f= utures, like HPX, you cannot easily express the completion of procedural op= erations. You just end up with horrible hacks such as hpx::future ("a= future of nothing"). This is why I believe that events are best as a low-l= evel layer, on top of which higher-level abstractions such as futures can b= e built. > > What is more difficult is to provide an easy to > > use syntax around it. >=20 > Hmm, what is difficult about procedure call? Basically, it is best if producers and consumers do not actually manipulate= raw pointers to the heap-allocated blocks. Otherwise, there is always a risk of a producer retaining access to the pro= duced block and later manipulating it in a racey fashion. A better option is to have a system where at the point where a producer "em= its" data, it loses access to the associated data block. Of course, this is= impossible to achieve in a perfectly fool-proof way, but we can make it ha= rder for developers to shoot themselves in the foot, using things like futu= res.