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!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Protected handlers & entry bodies Date: Mon, 19 Jan 2015 21:36:38 +0000 Organization: A noiseless patient Spider Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="8878eaae66d49f7d529ec3c7abf78fb7"; logging-data="30146"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/19Jb1KM+Gouw7JA6DObIvr6//l7KExfQ=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (darwin) Cancel-Lock: sha1:tkLu3gyfUmNJnIlCKSvWo+iAGyU= sha1:AGDzdXAT4amrNYxnaBMVdrecoKY= Xref: news.eternal-september.org comp.lang.ada:24611 Date: 2015-01-19T21:36:38+00:00 List-Id: "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.