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!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Reducing the cost of real-time software through a cyclic task abstraction for Ada Date: Wed, 07 Feb 2018 22:04:29 +0000 Organization: A noiseless patient Spider Message-ID: References: <40a33f37-7a25-4587-a80e-2ef5f7528264@googlegroups.com> <9f4aa92f-f3bf-44f8-8316-c66e7eb0f4bc@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: reader02.eternal-september.org; posting-host="a7c1b785df4e06150aa247e71475c30b"; logging-data="8143"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/7i0I13MauSYXuHhD6s+Qxlv5EPgxZbuM=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (darwin) Cancel-Lock: sha1:KjGszmtwSJjJOTAe1GRg++bQL7g= sha1:VQxSQOPJP0pREaaTO3W/TY7lhfY= Xref: reader02.eternal-september.org comp.lang.ada:50325 Date: 2018-02-07T22:04:29+00:00 List-Id: guyclaude.burger@gmail.com writes: > That paper is huge, no wonder no one (seems to) dares to review > it. Could you make a summary, or a short exposé on why "loop delay > until ..." or similar statements are not enough to implement neatly > the desired semantic ? Not that big for a thesis, though it does seem a bit repetitive. The pix seemed a bit OTT, I guess I'm just old-fashioned. And English. He made criticisms of the -sfp- RTSs which don't apply to the -full- versions; e.g. no memory allocation, no inheritance (and, by the way, the -sfp- version *does* provide memory allocation, just not deallocation). We have to remember that it takes a lot of time to work to a doctorate, and keeping up with AdaCore improvements wouldn't add a lot. The problem with implementing the desired task paradigms with 'delay until' etc is that although you could do it with a lot of distributed effort (including use of tasking libraries as in GNATCOLL) it wouldn't be easy to work out whether the system would meet its deadlines, with a tool or by hand. And there'd be lots of opportunity for mistakes. Another point I noticed was that he doesn't like the way an entry released by an interrupt handler runs in the context of the task that happened to be running at the time of the interrupt. I can't get too excited about that, the interrupt had to be handled, and the code in the entry shouldn't(*) be lengthy. He says (p.158) "running a protected procedure handler in response to an interrupt [...] invokes a context switch" which is not true. My personal view of the AdaCore BB RTS is that it's fiendishly complicated. I suppose that to meet all the ARM requirements it has to be. Some of this appears to be for portability. The package call graph is deeply nested. I ws interested to see the claim that AdaCore BB RTS won't allow an MCU to enter a low-power mode. I've not had occasion to try it out, but FreeRTOS (which my Cortex GNAT RTS[1] runs on) does support this. (*) not a good position to be in if your system is severely CPU-bound; but in that case, would you believe the theoretical calculations anyway? [1] https://github.com/simonjwright/cortex-gnat-rts