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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.182.230.107 with SMTP id sx11mr6269713obc.5.1456596373435; Sat, 27 Feb 2016 10:06:13 -0800 (PST) X-Received: by 10.182.19.129 with SMTP id f1mr81739obe.20.1456596373403; Sat, 27 Feb 2016 10:06:13 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!ok5no5102743igc.0!news-out.google.com!k1ni2808igd.0!nntp.google.com!ok5no5102736igc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 27 Feb 2016 10:06:13 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=83.9.207.1; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S NNTP-Posting-Host: 83.9.207.1 References: <7663896a-a15e-47fd-8c7e-54a1c20d8d0f@googlegroups.com> <2922ffdd-9678-4502-9bcb-8b199af91543@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <90861757-7eab-496c-8aeb-663e04c6085e@googlegroups.com> Subject: Re: Protected Objects and Interrupt Handlers From: Maciej Sobczak Injection-Date: Sat, 27 Feb 2016 18:06:13 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:29616 Date: 2016-02-27T10:06:13-08:00 List-Id: > I think this approach might have problems; if the PO doesn't expect to > be called in an interrupt context, it may do things (like block) which > an ISR should never do. Good point, but this problem is not easy to avoid. Note that protected proc= edures cannot be called when any other task is inside the entry, so there w= ill be some periods of time when calling the procedure will be prohibited n= o matter whether it is called from the handler or is itself a handler. How = this is done is another story, but disabling interrupts altogether seems to= be a very heavy-handed option. Note also that if the interrupt handler has= something to do, moving as much of this work outside of the protected obje= ct (that is, *before* calling the protected procedure) reduces the amount o= f time the handler is inside the critical section, so I would still defend = the idea of having the non-protected handler doing the data preparation and= then calling the protected procedure just for the data exchange. Interestingly, the C standard does not have any reasonable solution for thi= s, except the explicit provision for communication via some dedicated atomi= c primitive type. I mention this not to criticize C, but to point out that = in practice and depending on circumstances (ie. on the actual target), this= might be the only valid solution in Ada, too. --=20 Maciej Sobczak * http://www.inspirel.com