Re: protected type interrupts

REH a écrit :
I am having a disagreement with a compiler vendor. I am using a
protected type for an interrupt handler (see below). The handler
simply sets a boolean to true that an entry is using as a guard. The
entry is called by a task. Basically, the task is blocked until
signaled by the interrupt to do the processing. With newer versions of
their compiler, the computer resets. They say it is because they are
calling the entry at the interrupt level, and not the task level (we
process this in a task because we have to do things you cannot do in a
interrupt). They say the LRM allows them to do this. Is that true?
C.3.1 (17) allows them to pretty much anything. Apparently, a ceiling_priority is in effect (either because you specified it, or by default), thus your task inherits the ceiling of the protected type (which is an interrupt_priority), and this implementation seems to forbid an entry to be called at an interrupt level.

A work-around could be:
protected Relay_Object is

procedure Isr;

entry Process_Interrupt;

private

Triggered : Boolean := False;

end Relay_Object;

protected Interrupt_Object is

procedure Isr;
pragma Attach_Handler(Isr, XXX);
pragma Interrupt_Priority(XXX);

private

pragma Suppress(All_Checks, On => Isr);
end Interrupt_Object;

protected body Relay_Object is

procedure Isr is
begin
Triggered := True;
end Isr;

entry Process_Interrupt when Triggered is
begin
Triggered := False;

-- process interrrupt
end Process_Interrupt;

end Relay_Object;

protected body Interrupt_Object is

procedure Isr is
begin
Relay_Object.Isr;
end Isr;
end Interrupt_Object;

This way, the task is not calling a PO that serves as an interrupt handler, thus C.3.1 (17) does not apply.
--
---------------------------------------------------------
J-P. Rosen (rosen@xxxxxxxxx)
Visit Adalog's web site at http://www.adalog.fr
.

Relevant Pages

  • Re: Fixes for nforce2 hard lockup, apic, io-apic, udma133 covered
    ... The system reports the timer IRQ to be routed to pin 2, ... There's no workaround in the kernel as working it ... That entry appears due to conditions making the following entry being ... I don't know why the SCI interrupt is set up the second time here. ...
    (Linux-Kernel)
  • protected type interrupts
    ... I am having a disagreement with a compiler vendor. ... protected type for an interrupt handler. ... simply sets a boolean to true that an entry is using as a guard. ...
    (comp.lang.ada)
  • Re: Question about interrupt in MINIX3
    ... a new stack for use during the interrupt service. ... stack is determined by an entry in the Task State Segment. ... register values are saved on the frame, the stack pointer ...
    (comp.os.minix)
  • Re: Fixes for nforce2 hard lockup, apic, io-apic, udma133 covered
    ... > Now this is an explicit entry stating the 8254 timer is connected to ... Right, this means that there are multiple irq_2_pin entries, which isn't ... do system actually exist where the same interrupt wires simultaneously ...
    (Linux-Kernel)
  • Re: Question about interrupt in MINIX3
    ... a new stack for use during the interrupt service. ... stack is determined by an entry in the Task State Segment. ... moves from the last entry to the first entry of the stack frame. ...
    (comp.os.minix)