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.56.250 with SMTP id g55mr22765920qtc.18.1467478174888; Sat, 02 Jul 2016 09:49:34 -0700 (PDT) X-Received: by 10.157.34.202 with SMTP id y68mr1073723ota.4.1467478174846; Sat, 02 Jul 2016 09:49:34 -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!au2pb.net!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!w59no1578771qtd.1!news-out.google.com!o189ni15158ith.0!nntp.google.com!r1no9268741ige.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 2 Jul 2016 09:49:34 -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: Subject: Re: RFC: Prototype for a user threading library in Ada From: Hadrien Grasland Injection-Date: Sat, 02 Jul 2016 16:49:34 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 4320 X-Received-Body-CRC: 2643767267 Xref: news.eternal-september.org comp.lang.ada:31006 Date: 2016-07-02T09:49:34-07:00 List-Id: Le samedi 2 juillet 2016 15:18:58 UTC+2, Dmitry A. Kazakov a =C3=A9crit=C2= =A0: > On 2016-07-02 13: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 som= e help > >> there, too. > > > > Here's my view of this: people are heavily overusing shared mutable > > data in multitasking programs, >=20 > This is motivated by the hardware architecture of multi-cores with=20 > shared memory. Fair enough, but I would argue that outside of the realm of data-parallel a= lgorithms, most of the benefits of shared memory architectures reside in sh= aring constant data, not mutable one. In any hardware architecture that features caches, and in any compiler whos= e memory model allows instruction reordering, synchronization of shared mut= able data is always going to be problematic. So better do without that sync= hronization whenever practical. > > 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 > Event-controlled architecture is exposed to generators (life-locks), and= =20 > no less to dead-locks and race conditions. >=20 > From the software developing POV it is far worse than shared memory=20 > architecture. The only advantage it has over the former that it can be=20 > truly scalable while shared memory is a bottle neck. I would claim that if your architecture is based on a notion of data owners= hip and favors the model of moving data over that of concurrently accessing= it, then... - Performance does not have to suffer (if what you move around is pointers = or references to data, not the data itself) - Race conditions in the message-passing process are easy to deal with (jus= t do a memory fence before a thread sends data and after another receives i= t) As for deadlocks in event-driven programs, they do occur, but they are triv= ial to detect (since the task graph is explicit, one can just look for a cy= cle in it), and good interface design can make it hard to trigger accidenta= lly (if the event produced by a task A cannot be easily used as a dependenc= y of that same task).