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!news.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!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: Mon, 11 Jul 2016 14:40:19 -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 1468266016 626 24.196.82.226 (11 Jul 2016 19:40:16 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 11 Jul 2016 19:40:16 +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:31060 Date: 2016-07-11T14:40:19-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:nlnl0b$93q$1@gioia.aioe.org... > On 08/07/2016 02:03, Randy Brukardt wrote: ... >>> Are you not contemplating any real-time systems? If you are, what do you >>> use instead of priorites, to ensure that urgent activities are done in >>> time? >> >> I'm not contemplating hard-real-time systems (under 10ms response time). > > Some of our customers have 0.2ms response time requirement and that not > just local but over the network. Your customers wouldn't be a candidate for this implementation, then. >> I don't think it is possible to create implementation-independent code >> for >> those sorts of deadlines, and as such it doesn't really matter from a >> language perspective how that's done (it won't be portable in any case). > > I don't see why. Any reasonable implementation would do. An implementation > that does not preempt lower priority tasks is not reasonable. If you > wanted to push the argument you would end up with disabling hardware > interrupts. Your definition of reasonable and mine are obviously incompatible. Hardware interrupts are evil; possibly a necessary evil but still evil and one wants to minimize them as much as possible. Obviously you disagree. >> I'm unconvinced that the way to ensure that "urgent activies" are done is >> some sort of magic (and priorities are essentially magic). I'd rather >> make >> sure that no task is hogging the system, and avoid overcommitting. That >> usually happens naturally, and in the unusual case where it doesn't, >> there's >> almost always someplace where adding a synchronization point (usually a >> "Yield" aka delay 0.0) fixes the problem. > > No it does not and it is a *very* bad design, because it distributes > making the decision to switch to the parts of the software which must know > nothing about the reason when switching is necessary. E.g. that a task > solving some differential equation decides whether to switch to the > keyboard interrupt handler. That belongs to the keyboard driver, not to > the equation solver. Wrong. In this scheme *all* software switches, all the time. Only the task supervisor is making any decisions, but it is getting the opportunity to do so at reasonable intervals. Neither the keyboard nor the diffy-Q solver has anything to do with it. I agree that having to put in such choices manually isn't a good idea, but I wasn't suggesting that (outside of user-written I/O that doesn't use language-defined or implementation-defined libraries). The compiler would do it at appropriate points. > Yield is a premature optimization of worst kind and I bet it is highly > inefficient comparing to preemptive scheduling on any modern hardware. Dunno; it wasn't very efficient on MS-DOS, but the problem there was that MS-DOS itself wasn't re-enterant. With multiple threads running at all times, the equation is very different. I don't want to make a claim that it will be better in some sense, the experiment has to be done before any answer is known. (Task switching appears to be *much* cheaper in this model, so the question remains whether that savings makes up for the extra cost.) > It is just like arguing for return codes over exceptions. Given that almost none of this is visible to the Ada user, I don't see the analogy. (And certainly, return codes are much more efficient than exceptions; the problem is the distribution of concerns. That's not happening here.) Randy.