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.250.201 with SMTP id ze9mr42873490obc.0.1456413265916; Thu, 25 Feb 2016 07:14:25 -0800 (PST) X-Received: by 10.182.246.231 with SMTP id xz7mr224725obc.5.1456413265883; Thu, 25 Feb 2016 07:14:25 -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!border1.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!hb3no8943855igb.0!news-out.google.com!pn7ni2059igb.0!nntp.google.com!hb3no8943854igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 25 Feb 2016 07:14:25 -0800 (PST) In-Reply-To: <7663896a-a15e-47fd-8c7e-54a1c20d8d0f@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=46.21.217.1; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S NNTP-Posting-Host: 46.21.217.1 References: <7663896a-a15e-47fd-8c7e-54a1c20d8d0f@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <2922ffdd-9678-4502-9bcb-8b199af91543@googlegroups.com> Subject: Re: Protected Objects and Interrupt Handlers From: Maciej Sobczak Injection-Date: Thu, 25 Feb 2016 15:14:25 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:29604 Date: 2016-02-25T07:14:25-08:00 List-Id: > This is more of a curiosity, but I have noticed that a lot of embedded Ad= a examples that I run across use a protected type object to wrap the ISR fo= r a particular interrupt. The way I understand it is that in a more complex system interrupt routines= are supposed to be as short as possible and only do the necessary work of = *notifying* the regular tasks that something of interest have happened, pos= sibly translating it into some higher-level concept like message arrival or= button being pressed, etc. The regular tasks are then responsible for actu= al processing of this information. In such a scheme, protected objects readily provide the necessary tasking p= attern - the regular tasks *wait* for some work to do, perhaps in terms of = calling appropriate *entry* of the protected object. The interrupt (which i= s a low-level concept) is physically delivered to the *procedure* in the pr= otected object, where some predicate is set so that the entry-waiting task = is let in and allowed to proceed. This is no different from a regular work-queue pattern, where "work item" i= s delivered to some protected procedure and a worker task gets that item fr= om the entry, possibly blocking if at the given moment there is no item to = process. The idea is to retain this high-level multitasking pattern with in= terrupts, which I find pretty nice. Note also that by tying interrupts with protected objects, you retain the p= ossibility to reason about different properties of the code (like freedom f= rom deadlocks) in the same way as in a regular multitasking program. This i= s an added value. Last but no least - Simon has pointed you towards an article (a book chapte= r, in fact) where the interrupts are handled by regular procedures instead = - as an author of that text I feel responsible for clarifying why - the rea= son is that the book consistently assumes a zero-runtime execution platform= , where the necessary scaffolding for protected objects (namely: actual syn= chronization) simply does not exist. Note also that it is easy to combine these two approaches - just let the in= terrupt handler (a procedure) interact with a dedicated protected object (b= y forwarding to its procedures) as if it was a regular work-item producing = task - which, conceptually, it really is. --=20 Maciej Sobczak * http://www.inspirel.com