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.66.138.81 with SMTP id qo17mr22011733pab.26.1467457996872; Sat, 02 Jul 2016 04:13:16 -0700 (PDT) X-Received: by 10.157.29.3 with SMTP id m3mr1040304otm.2.1467457996821; Sat, 02 Jul 2016 04:13:16 -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!jk6no9014433igb.0!news-out.google.com!o189ni14912ith.0!nntp.google.com!jk6no9014427igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 2 Jul 2016 04:13:16 -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 11:13:16 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:31004 Date: 2016-07-02T04:13:16-07:00 List-Id: Le samedi 2 juillet 2016 06:36:09 UTC+2, Randy Brukardt a =C3=A9crit=C2=A0: > But I don't think that really helps the race and deadlock issues that are= =20 > the real problem with programming with Ada tasks. I'd like to find some h= elp=20 > 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, whic= h in turn people attempt to fix with locks, thusly killing their performanc= e and introducing deadlocks. In many cases, better performance and correctness can be easily achieved by= moving to asynchronous tasking runtimes, where the runtime internally mana= ges an event-based dependency graph of tasks that can be processed condurre= ntly, and data is kept task-private but can be moved around between tasks. But shared mutable data is necessary to the efficient implementation of dat= a-parallel algorithms, so it should remain available to expert programmers. What I would love in the end is some kind of static analysis tool that warn= s people about shared mutable data in multitasking programs, but gives a wa= y to bypass the warning to people who actually know what they are doing. But to make this warning useful would also entail introducing a notion of "= deferred constants", that is, values which are defined at runtime but will = not be modified subsequently. Otherwise, there would be too many false posi= tives about program parameters that are loaded at runtime.