protected type interrupts

protected type interrupts

[REH]

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?  I
call the entry from a task, but its allow to be executed in the
interrupt handler.  That does not seem right.

  protected Interrupt_Object is

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

    entry Process_Interrupt;

  private

    pragma Suppress(All_Checks, On => Isr);

    Triggered : Boolean := False;

  end Interrupt_Object;

  protected body Interrupt_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 Interrupt_Object;

  task body Interrupt_Task is
  begin
    loop
      Interrupt_Object.Process_Interrupt;
    end loop;
  end Interrupt_Task;

Re: protected type interrupts

[Jean-Pierre Rosen]

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@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: protected type interrupts

[REH]

Jean-Pierre Rosen wrote:
> 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.
>
Thanks for the reference.  Is your work-around valid?  Isn't calling
Relay_Object.Isr a potentially blocking operation, and thus a bad thing
to do in an interrupt?

Another work-around suggested to me was to move the processing logic
out of the entry and into the task, and just use the entry for the
triggerring.  What do you think about this?

REH

Re: protected type interrupts

[Adam Beneschan]

REH wrote:

> Thanks for the reference.  Is your work-around valid?  Isn't calling
> Relay_Object.Isr a potentially blocking operation, and thus a bad thing
> to do in an interrupt?

I don't think it's potentially blocking... Relay_Object.Isr is a
procedure, and as I read 9.5.1, a call to a protected *procedure* is
not a potentially blocking operation unless it's done from the same
protected object.  A call on a protected *entry* would be potentially
blocking.  [This is from the Ada 95 manual.  If this has changed in Ada
0Y, I can't tell because www.adaic.com isn't responding.]

                                     -- Adam

Re: protected type interrupts

[REH]

Adam Beneschan wrote:
> REH wrote:
>
> > Thanks for the reference.  Is your work-around valid?  Isn't calling
> > Relay_Object.Isr a potentially blocking operation, and thus a bad thing
> > to do in an interrupt?
>
> I don't think it's potentially blocking... Relay_Object.Isr is a
> procedure, and as I read 9.5.1, a call to a protected *procedure* is
> not a potentially blocking operation unless it's done from the same
> protected object.  A call on a protected *entry* would be potentially
> blocking.  [This is from the Ada 95 manual.  If this has changed in Ada
> 0Y, I can't tell because www.adaic.com isn't responding.]
>

I don't understand.  How can a procedure within a protected object
modify data internal to the object in a thread-safe way without the
potentially blocking effect of enforcing mutual exclusion?  If one task
is "using" the object, and another calls one of the object's
procedures, would the second task not be blocked until the first one
exits the object?  

REH

Re: protected type interrupts

[Adam Beneschan]

REH wrote:
> Adam Beneschan wrote:
> > REH wrote:
> >
> > > Thanks for the reference.  Is your work-around valid?  Isn't calling
> > > Relay_Object.Isr a potentially blocking operation, and thus a bad thing
> > > to do in an interrupt?
> >
> > I don't think it's potentially blocking... Relay_Object.Isr is a
> > procedure, and as I read 9.5.1, a call to a protected *procedure* is
> > not a potentially blocking operation unless it's done from the same
> > protected object.  A call on a protected *entry* would be potentially
> > blocking.  [This is from the Ada 95 manual.  If this has changed in Ada
> > 0Y, I can't tell because www.adaic.com isn't responding.]
> >
>
> I don't understand.  How can a procedure within a protected object
> modify data internal to the object in a thread-safe way without the
> potentially blocking effect of enforcing mutual exclusion?  If one task
> is "using" the object, and another calls one of the object's
> procedures, would the second task not be blocked until the first one
> exits the object?

I'm just reading what the RM says.  But, although I'm not an expert at
this, I don't believe your argument makes sense given the way protected
objects are supposed to work.  A task cannot, of course, access data
internal to a protected object directly; it has to call one of the PO's
subprograms or entries to get it.  When it does so, then assuming
Ceiling_Locking is in effect, no other task can use the PO---but it's
not because other tasks are blocked, it's simply because the protected
action runs at a higher priority than any task that could use the PO
(and the protected action is supposed to complete very quickly).  So no
mutual exclusion or blocking is necessary when calling protected
subprograms.  At least I think that's how it works.

                                 -- Adam

Re: protected type interrupts

[REH]

Adam Beneschan wrote:
> I'm just reading what the RM says.  But, although I'm not an expert at
> this, I don't believe your argument makes sense given the way protected
> objects are supposed to work.  A task cannot, of course, access data
> internal to a protected object directly; it has to call one of the PO's
> subprograms or entries to get it.  When it does so, then assuming
> Ceiling_Locking is in effect, no other task can use the PO---but it's
> not because other tasks are blocked, it's simply because the protected
> action runs at a higher priority than any task that could use the PO
> (and the protected action is supposed to complete very quickly).  So no
> mutual exclusion or blocking is necessary when calling protected
> subprograms.  At least I think that's how it works.
>
>                                  -- Adam

That makes sense.  Thanks.

REH

Re: protected type interrupts

[Jean-Pierre Rosen]

Adam Beneschan a �crit :
> I'm just reading what the RM says.  But, although I'm not an expert at
> this, I don't believe your argument makes sense given the way protected
> objects are supposed to work.  A task cannot, of course, access data
> internal to a protected object directly; it has to call one of the PO's
> subprograms or entries to get it.  When it does so, then assuming
> Ceiling_Locking is in effect, no other task can use the PO---but it's
> not because other tasks are blocked, it's simply because the protected
> action runs at a higher priority than any task that could use the PO
> (and the protected action is supposed to complete very quickly).  So no
> mutual exclusion or blocking is necessary when calling protected
> subprograms.  At least I think that's how it works.
> 
Hmmm... yes, as long as you are running on a mono-processor. But the 
rules must take care of multi-processors, too. In that case, there is 
some blocking, but it can be implemented by spin-locking, thus avoiding 
context switches (see my previous message).

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: protected type interrupts

[Jeffrey R. Carter]

REH wrote:
> 
> I don't understand.  How can a procedure within a protected object
> modify data internal to the object in a thread-safe way without the
> potentially blocking effect of enforcing mutual exclusion?  If one task
> is "using" the object, and another calls one of the object's
> procedures, would the second task not be blocked until the first one
> exits the object?  

In the terms of the ARM, mutual exclusion is not considered potentially 
blocking. Only waiting for data synchronization is potentially blocking. 
Since protected actions are supposed to be short and quick, and cannot 
perform potentially blocking operations, mutual exclusion cannot delay a 
task for very long. On the other hand, waiting for an entry barrier to 
become true can take forever.

Many external actions, such as I/O, are also considered potentially 
blocking.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail
07

Re: protected type interrupts

[Jean-Pierre Rosen]

REH a �crit :

> I don't understand.  How can a procedure within a protected object
> modify data internal to the object in a thread-safe way without the
> potentially blocking effect of enforcing mutual exclusion?  If one task
> is "using" the object, and another calls one of the object's
> procedures, would the second task not be blocked until the first one
> exits the object?  
> 
The goal of the "potentially blocking" rule is to prevent *unbounded* 
blocking. Short blockings, such as those require to provide mutual 
exclusion, are OK, because thay are bounded.

Think of it this way: if it can be implemented on a multi-processor by a 
simple spin-lock, it is not potentially blocking. If it requires a 
queue, and being awaken depends on some non determinable condition, it 
is potentially blocking.
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: protected type interrupts

[Jeffrey R. Carter]

REH wrote:
> 
> Another work-around suggested to me was to move the processing logic
> out of the entry and into the task, and just use the entry for the
> triggerring.  What do you think about this?

That is probably a good idea. Your protected object has a ceiling 
priority that is an interrupt priority, so the entry body, whether 
executed by the calling task or by the thread of control from the 
interrupt, is executed at an interrupt priority. It's not a good idea to 
do any extensive processing at an interrupt priority. Moving the 
processing into the task allows it to be done at a lower priority.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail
07

Re: protected type interrupts

[Jean-Pierre Rosen]

REH a �crit :
> Jean-Pierre Rosen wrote:
> Thanks for the reference.  Is your work-around valid?  Isn't calling
> Relay_Object.Isr a potentially blocking operation, and thus a bad thing
> to do in an interrupt?
No, calling a protected *procedure* is not potentially-blocking (unlike 
calling a protected *entry*). If your compiler has ceiling_locking by 
defauly you may have to adjust the priority, though.

> Another work-around suggested to me was to move the processing logic
> out of the entry and into the task, and just use the entry for the
> triggerring.  What do you think about this?
Nothing, since I don't know what was a problem with your original 
design. As far as I understand, it's the mere fact of calling an entry 
of a protected object that serves as interrupt handler, with a priority 
in Interrupt_Priority range. So I don't think that moving the logic 
would change anything, as long as you still call the entry;

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: protected type interrupts

[Simon Wright]

"REH" <spamjunk@stny.rr.com> writes:

> 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.

So why do they support POs as interrupt handlers at all? what do they
expect you to do?

Re: protected type interrupts

[Jeffrey R. Carter]

REH wrote:
> 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?  I
> call the entry from a task, but its allow to be executed in the
> interrupt handler.  That does not seem right.

If a call to a procedure or entry of a protected object changes the 
barrier on another entry to True, the thread of control that changed the 
barrier is allowed to execute the newly open entry on behalf of the task 
that called it. So the entry is not being executed in the interrupt 
handler, but by the thread of control that called the interrupt handler.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail
07

Re: protected type interrupts

[Jean-Pierre Rosen]

Jeffrey R. Carter a �crit :
> If a call to a procedure or entry of a protected object changes the 
> barrier on another entry to True, the thread of control that changed the 
> barrier is allowed to execute the newly open entry on behalf of the task 
> that called it. So the entry is not being executed in the interrupt 
> handler, but by the thread of control that called the interrupt handler.
> 
But since you specified a priority for the PO (and assuming 
priority_ceiling), you still execute at interrupt priority. Depending on 
the hardware and how priorities are managed, this may delay or hide 
actual interrupts.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: protected type interrupts

[REH]

"Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message 
news:mf6mce.8k2.ln@hunter.axlog.fr...
> But since you specified a priority for the PO (and assuming 
> priority_ceiling), you still execute at interrupt priority. Depending on 
> the hardware and how priorities are managed, this may delay or hide actual 
> interrupts.
>

Are you saying it may be better not to specify a priority?

REH

Re: protected type interrupts

[Jean-Pierre Rosen]

REH a �crit :
> "Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message 
> news:mf6mce.8k2.ln@hunter.axlog.fr...
>> But since you specified a priority for the PO (and assuming 
>> priority_ceiling), you still execute at interrupt priority. Depending on 
>> the hardware and how priorities are managed, this may delay or hide actual 
>> interrupts.
>>
> 
> Are you saying it may be better not to specify a priority?
> 
Not exactly. If your compiler doesn't use priority_ceiling by default 
(and you didn't specify it), then the priority is ignored.

Otherwise, the default priority of a protected object is Priority'Last 
(D.3(11)), which will result in ceiling violation if called from a PO 
which has a priority in the Interrupt_Priority range. You should then 
specify a priority at least as high as the one of the other PO.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: protected type interrupts

[Jeffrey R. Carter]

Jean-Pierre Rosen wrote:
>>
> But since you specified a priority for the PO (and assuming 
> priority_ceiling), you still execute at interrupt priority. Depending on 
> the hardware and how priorities are managed, this may delay or hide 
> actual interrupts.

Right. I said that in another message, IIRC. The message you were 
replying to was mostly nit picking, correcting the OP's assumption that 
the entry was being executed BY the interrupt handler.

-- 
Jeff Carter
"This school was here before you came,
and it'll be here before you go."
Horse Feathers
48

Re: protected type interrupts

[REH]

"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> wrote in message 
news:bvJHg.152959$1i1.59895@attbi_s72...
>
> Right. I said that in another message, IIRC. The message you were replying 
> to was mostly nit picking, correcting the OP's assumption that the entry 
> was being executed BY the interrupt handler.
>
It's not my assumption.  It IS being executing by the handler, and the 
compiler vender says the LRM allows them to do so.  References to LRM given 
here show they are correct.  My assumption (that was proven incorrect) was 
that it should been executed by the task that called it.  The standard 
states that this cannot be relied upon (which explains why you cannot call 
"current_task" from an entry).

REH

Re: protected type interrupts

[Jeffrey R. Carter]

REH wrote:
>>
> It's not my assumption.  It IS being executing by the handler, and the 
> compiler vender says the LRM allows them to do so.  References to LRM given 
> here show they are correct.  My assumption (that was proven incorrect) was 
> that it should been executed by the task that called it.  The standard 
> states that this cannot be relied upon (which explains why you cannot call 
> "current_task" from an entry).

No. It may be executed by the same thread of control that executed the 
interrupt handler, but that is not the same thing as executing it from 
the protected procedure that is the interrupt handler. The ARM does not 
allow the latter.

-- 
Jeff Carter
"This school was here before you came,
and it'll be here before you go."
Horse Feathers
48

Re: protected type interrupts

[REH]

"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> wrote in message 
news:00SHg.153600$1i1.101654@attbi_s72...
> No. It may be executed by the same thread of control that executed the 
> interrupt handler,

This is what I was trying to say.

>but that is not the same thing as executing it from the protected procedure 
>that is the interrupt handler.

I didn't mean to say this.

Thanks,

REH