comp.lang.ada
 help / color / mirror / Atom feed
From: Jere <jere.groups@gmail.com>
Subject: Re: Protected Objects and Interrupt Handlers
Date: Wed, 24 Feb 2016 06:38:49 -0800 (PST)
Date: 2016-02-24T06:38:49-08:00	[thread overview]
Message-ID: <85b5c378-dbaf-459b-afcd-dc5ed7692ee9@googlegroups.com> (raw)
In-Reply-To: <lya8mrm3br.fsf@pushface.org>

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.
> 
> You may have traced the ARM stuff on interrupt handling (C.3ff, [2]).
> 
> I wrote up how GNAT/Ravenscar deals with this at [3] (section "Interrupt
> handling", about 2/3 of the way down).
> 
> [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 small 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 interrupt the main processing (which would include all the tasks/threads/processes/whathaveya).  I can understand from a general view point they are all threads of execution, but interrupt service routines as I have typically been able 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 the 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 processing using some sort of Runtime construct but with additional overhead such 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 keep multiple tasks from changing the data in the protected object at the same time than is needed for interrupts.  For interrupts I would expect something more like disabling interrupts to be appropriate.  Does a protected object/procedure behave differently for interrupts than it does for tasks under the hood and Ada is able to handle all those details based on the existence of the pragma used?

I'll read through the links you provided to get more info as well.  Thank you for those!

  reply	other threads:[~2016-02-24 14:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-23 22:25 Protected Objects and Interrupt Handlers Jere
2016-02-23 23:09 ` Simon Wright
2016-02-24 14:38   ` Jere [this message]
2016-02-24 18:29     ` Simon Wright
2016-02-24 21:37       ` Jere
2016-02-25 15:14 ` Maciej Sobczak
2016-02-25 15:59   ` Simon Wright
2016-02-26  3:20     ` Dennis Lee Bieber
2016-02-26  8:12       ` Simon Wright
2016-02-27 18:06     ` Maciej Sobczak
2016-02-25 16:02   ` Simon Wright
2016-02-25 17:40     ` Tero Koskinen
2016-02-25 19:49       ` Simon Wright
2016-03-13  8:10         ` Simon Wright
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox