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!gegeweb.org!news.ecp.fr!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: RFC: Prototype for a user threading library in Ada Date: Fri, 24 Jun 2016 18:00:35 -0500 Organization: JSA Research & Innovation Message-ID: References: <58b78af5-28d8-4029-8804-598b2b63013c@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1466809234 13295 24.196.82.226 (24 Jun 2016 23:00:34 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 24 Jun 2016 23:00:34 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:30903 Date: 2016-06-24T18:00:35-05:00 List-Id: Dmitry A. Kazakov" wrote in message news:nkinr0$1h8t$1@gioia.aioe.org... > On 24/06/2016 00:12, Randy Brukardt wrote: > >> That wasn't my question; I'm wondering the motivation for these features >> in >> terms of parallelization. > > Because fine-grained (tightly coupled) parallelism is dead on arrival if > you use synchronous exchange. You cannot wait for a response without > imposing huge accumulating latencies. Parallelism, in general, is DOA if you need any significant exchange at all. As you say, that makes the effort effectively sequential. The cases where it works tend to use order-independent accumlators and fairly large chunks of accumulation. >> In today's world, it's impossible to consider any >> feature in a purely sequential manner. The expressiveness gain (if any) >> is >> secondary. And the OP was talking about parallelism, not generators. > > Of course you can. Nobody is capable to write anything more or less large > in a data event-controlled way. All logic of exchanges between parties is > always strictly sequential: you compute, publish data, get subscribed > data, compute again. Right. If there's a lot of exchange, it's not a candidate for parallelism. >> The generator proposal as expressed in AI12-0197-1 is just too expensive >> to >> consider for a purely sequential feature. > > I don't see much use in the proposal. The key feature must be the points > where the "task" yields control, enters non-busy wait for an external > event. Ideally it must be shaped as an accept statement or an entry call. Jean-Pierre Rosen proposed a ""passive task" feature as an alternative to the generator proposal. It uses the existing task syntax, but gets rid of the thread of control. Of course, Janus/Ada implements all tasks that way today, so I don't see a lot of benefit to that. But I can see where it might help other implementations. >> For Janus/Ada on Windows, we'd >> either have to throw away 1/3 of the back-end of the compiler (and >> generally >> use slower instructions in some cases, impacting all code), or implement >> these *exactly* as we do tasks (with a TCB, context switching, and so >> on). >> [Not to mention the extensive changes needed to the front-end.] For >> something to be worth that sort of effort, it has to benefit a large >> percentage of programs. This (as a purely sequential feature) doesn't do >> that. > > I don't understand the point. All tasks are sequential. That didn't > prevent them being used in parallel computing. The feature as proposed can't be used in a task unless one (manually) adds locking, meaning you still have all of the possibilities for deadlock and race conditions. I believe that if we're going to advance parallelism at all, we have to do something to make it possible to write (sufficiently restricted and compile-time checked) code where one doesn't need to worry about those things. After all, the main reason that it's too hard to write parallel code is the need to carefully consider every possible deadlock and race condition. Otherwise, something like Parafin would provide everything needed and Ada clearly would be the choice for parallel code. ;-) So I don't see any reason to add any new sequential features that add to, rather than reduce, the possibilities of deadlock and races. Certainly not if they take a lot of effort to implement, and don't seem to have general utility. Randy.