Re: Protected Objects and Interrupt Handlers

[Maciej Sobczak <see.my.homepage@gmail.com>]

> 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 procedures cannot be called when any other task is inside the entry, so there will be some periods of time when calling the procedure will be prohibited no 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 object (that is, *before* calling the protected procedure) reduces the amount of 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 this, except the explicit provision for communication via some dedicated atomic 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.

-- 
Maciej Sobczak * http://www.inspirel.com