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!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Protected handlers & entry bodies Date: Tue, 20 Jan 2015 16:05:40 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1421791541 9370 24.196.82.226 (20 Jan 2015 22:05:41 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 20 Jan 2015 22:05:41 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:24649 Date: 2015-01-20T16:05:40-06:00 List-Id: "Simon Wright" wrote in message news:lytwzmo3kp.fsf@pushface.org... > "Randy Brukardt" writes: > >> "Simon Wright" wrote in message >> news:lyy4ozof2x.fsf@pushface.org... >>> This is for a Ravenscar RTS. >>> >>> In GNAT, if an protected entry's guard is opened by a protected >>> procedure, the entry code is executed in the thread of control (task) >>> that called the protected procedure. I haven't looked in detail at >>> the normal RTS, but I suspect that after a protected procedure call >>> each of the entries is serviced (the guard is evaluated, and if open >>> the entry code is called). In Ravenscar, there's only one entry, so >>> things are a bit simpler. >>> >>> The generated code appears to do exactly the same for protected >>> procedure handlers, in which case the entry code is going to be >>> executed in the thread of the ISR. >> >> Here you lost me. A protected procedure /= an entry. >> >>> This may well require restrictions on what can be done in the >>> entry. Is this covered by C.3.1(17)? >> >> What entry? There's no entry in a protected procedure. C.3.1(17) >> allows restrictions on what appears in the body of a interrupt-called >> protected procedure. One would expect that to ban anything that causes >> trouble. I'd expect any sort of blocking operation to be banned there >> (but of course they already are bounded errors by 9.5.1(8)). > > The PDL below shows how GNAT executes a protected procedure which is > being used as an interrupt handler. This code is the same whether the > protected procedure is being called from Ada or as an interrupt handler > (so the details of locking/unlocking and waking the entry's caller will > need to be different). > > interrupt occurs and starts executing protected procedure wrapper > lock the PO > execute the protected procedure body > call System.Tasking.Protected_Objects.Single_Entry.Service_Entry (PO) > if there is a blocked entry call then > if the barrier has become open then > execute the entry body IN THE ISR CONTEXT > unlock the PO > wakeup the entry's caller > else > unlock the PO > end if > else > unlock the PO > end if > return > return from interrupt > > I was more concerned that there may be (non-Ada, perhaps) restrictions > on what can be done in an interrupt context. An example of such a > restriction (admittedly not one I'd hope to see an entry body coming > across) is that FreeRTOS has some API calls that MUST NOT be made from a > task context and have a version that MUST ONLY be called from an > interrupt context. I see. Your point is that GNAT is buggy and that's likely to cause problems in some obscure and non-reproducible cases. But this has nothing to do with the language. Just because there is a permission to do something (use some other task to execute an entry body) does not mean that it should be used, especially if that is potentially causing problems. Of course, this may not really be a problem in practice because of something that happens elsewhere. (Perhaps there is some different flow in the case of an ISR - I really would not expect them to work the same as a regular call.) Randy.