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.107.128.102 with SMTP id b99mr37999749iod.1.1456324729465; Wed, 24 Feb 2016 06:38:49 -0800 (PST) X-Received: by 10.182.112.202 with SMTP id is10mr463390obb.7.1456324729283; Wed, 24 Feb 2016 06:38:49 -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!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!w104no3162825qge.1!news-out.google.com!h70ni5qge.0!nntp.google.com!w104no3162810qge.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 24 Feb 2016 06:38:49 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=138.162.0.42; posting-account=9yqilwkAAAAlbxojEc6DW1OEOsACipCN NNTP-Posting-Host: 138.162.0.42 References: <7663896a-a15e-47fd-8c7e-54a1c20d8d0f@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <85b5c378-dbaf-459b-afcd-dc5ed7692ee9@googlegroups.com> Subject: Re: Protected Objects and Interrupt Handlers From: Jere Injection-Date: Wed, 24 Feb 2016 14:38:49 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:29598 Date: 2016-02-24T06:38:49-08:00 List-Id: On Tuesday, February 23, 2016 at 6:09:30 PM UTC-5, Simon Wright wrote: > A task is a thread of execution, and so is an interrupt, so it seems > natural to use the same mechanism to do interrupt-to-task communication > as for task-to-task; the originating task/interrupt calls a procedure in > the PO which results in waking up the listening task. >=20 > You may have traced the ARM stuff on interrupt handling (C.3ff, [2]). >=20 > I wrote up how GNAT/Ravenscar deals with this at [3] (section "Interrupt > handling", about 2/3 of the way down). >=20 > [1] http://www.inspirel.com/articles/Ada_On_Cortex_Interrupts.html > [2] http://www.ada-auth.org/standards/12rm/html/RM-C-3.html > [3] http://forward-in-code.blogspot.co.uk/2015/06/building-runtime-system= -for-arm-eabi.html Thanks for those links and the discussion. Keep in mind I come from a smal= l micro world, so I am used to handling interrupts directly, which is part = of my confusion. Interrupts happen at the lowest level and tend to interru= pt the main processing (which would include all the tasks/threads/processes= /whathaveya). I can understand from a general view point they are all thre= ads of execution, but interrupt service routines as I have typically been a= ble to use them operate very differently than a task or thread or process. = ISR's are jumped to directly by the micro and are manually serviced with t= he hardware handling context switches (as I am used to at least). While as= I understand it, tasks are a higher level concept that happens in main pro= cessing using some sort of Runtime construct but with additional overhead s= uch as data structures to hold the task state for context switches. I would expect a protected entry or procedure to employ a different type of= synchronization construct (maybe similar to a mutex/semiphore/etc.??) to k= eep multiple tasks from changing the data in the protected object at the sa= me time than is needed for interrupts. For interrupts I would expect somet= hing more like disabling interrupts to be appropriate. Does a protected ob= ject/procedure behave differently for interrupts than it does for tasks und= er the hood and Ada is able to handle all those details based on the existe= nce of the pragma used? I'll read through the links you provided to get more info as well. Thank y= ou for those!