Protected handlers & entry bodies

Protected handlers & entry bodies

[Simon Wright]

This is for a Ravenscar RTS.

In GNAT, if an protected entry's guard is opened by a protected
procedure, the entry code is executed in the thread of control (task)
that called the protected procedure. I haven't looked in detail at the
normal RTS, but I suspect that after a protected procedure call each of
the entries is serviced (the guard is evaluated, and if open the entry
code is called). In Ravenscar, there's only one entry, so things are
a bit simpler.

The generated code appears to do exactly the same for protected
procedure handlers, in which case the entry code is going to be executed
in the thread of the ISR.

This may well require restrictions on what can be done in the entry. Is
this covered by C.3.1(17)?

Re: Protected handlers & entry bodies

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lyy4ozof2x.fsf@pushface.org...
> This is for a Ravenscar RTS.
>
> In GNAT, if an protected entry's guard is opened by a protected
> procedure, the entry code is executed in the thread of control (task)
> that called the protected procedure. I haven't looked in detail at the
> normal RTS, but I suspect that after a protected procedure call each of
> the entries is serviced (the guard is evaluated, and if open the entry
> code is called). In Ravenscar, there's only one entry, so things are
> a bit simpler.
>
> The generated code appears to do exactly the same for protected
> procedure handlers, in which case the entry code is going to be executed
> in the thread of the ISR.

Here you lost me. A protected procedure /= an entry.

> This may well require restrictions on what can be done in the entry. Is
> this covered by C.3.1(17)?

What entry? There's no entry in a protected procedure. C.3.1(17) allows 
restrictions on what appears in the body of a interrupt-called protected 
procedure. One would expect that to ban anything that causes trouble. I'd 
expect any sort of blocking operation to be banned there (but of course they 
already are bounded errors by 9.5.1(8)).

                           Randy.

Re: Protected handlers & entry bodies

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Simon Wright" <simon@pushface.org> wrote in message 
> news:lyy4ozof2x.fsf@pushface.org...
>> This is for a Ravenscar RTS.
>>
>> In GNAT, if an protected entry's guard is opened by a protected
>> procedure, the entry code is executed in the thread of control (task)
>> that called the protected procedure. I haven't looked in detail at
>> the normal RTS, but I suspect that after a protected procedure call
>> each of the entries is serviced (the guard is evaluated, and if open
>> the entry code is called). In Ravenscar, there's only one entry, so
>> things are a bit simpler.
>>
>> The generated code appears to do exactly the same for protected
>> procedure handlers, in which case the entry code is going to be
>> executed in the thread of the ISR.
>
> Here you lost me. A protected procedure /= an entry.
>
>> This may well require restrictions on what can be done in the
>> entry. Is this covered by C.3.1(17)?
>
> What entry? There's no entry in a protected procedure. C.3.1(17)
> allows restrictions on what appears in the body of a interrupt-called
> protected procedure. One would expect that to ban anything that causes
> trouble. I'd expect any sort of blocking operation to be banned there
> (but of course they already are bounded errors by 9.5.1(8)).

The PDL below shows how GNAT executes a protected procedure which is
being used as an interrupt handler. This code is the same whether the
protected procedure is being called from Ada or as an interrupt handler
(so the details of locking/unlocking and waking the entry's caller will
need to be different).

   interrupt occurs and starts executing protected procedure wrapper
      lock the PO
      execute the protected procedure body
      call System.Tasking.Protected_Objects.Single_Entry.Service_Entry (PO)
         if there is a blocked entry call then
            if the barrier has become open then
               execute the entry body IN THE ISR CONTEXT
               unlock the PO
               wakeup the entry's caller
            else
               unlock the PO
            end if
         else
            unlock the PO
         end if
         return
      return from interrupt

I was more concerned that there may be (non-Ada, perhaps) restrictions
on what can be done in an interrupt context. An example of such a
restriction (admittedly not one I'd hope to see an entry body coming
across) is that FreeRTOS has some API calls that MUST NOT be made from a
task context and have a version that MUST ONLY be called from an
interrupt context.

Re: Protected handlers & entry bodies

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lytwzmo3kp.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> "Simon Wright" <simon@pushface.org> wrote in message
>> news:lyy4ozof2x.fsf@pushface.org...
>>> This is for a Ravenscar RTS.
>>>
>>> In GNAT, if an protected entry's guard is opened by a protected
>>> procedure, the entry code is executed in the thread of control (task)
>>> that called the protected procedure. I haven't looked in detail at
>>> the normal RTS, but I suspect that after a protected procedure call
>>> each of the entries is serviced (the guard is evaluated, and if open
>>> the entry code is called). In Ravenscar, there's only one entry, so
>>> things are a bit simpler.
>>>
>>> The generated code appears to do exactly the same for protected
>>> procedure handlers, in which case the entry code is going to be
>>> executed in the thread of the ISR.
>>
>> Here you lost me. A protected procedure /= an entry.
>>
>>> This may well require restrictions on what can be done in the
>>> entry. Is this covered by C.3.1(17)?
>>
>> What entry? There's no entry in a protected procedure. C.3.1(17)
>> allows restrictions on what appears in the body of a interrupt-called
>> protected procedure. One would expect that to ban anything that causes
>> trouble. I'd expect any sort of blocking operation to be banned there
>> (but of course they already are bounded errors by 9.5.1(8)).
>
> The PDL below shows how GNAT executes a protected procedure which is
> being used as an interrupt handler. This code is the same whether the
> protected procedure is being called from Ada or as an interrupt handler
> (so the details of locking/unlocking and waking the entry's caller will
> need to be different).
>
>   interrupt occurs and starts executing protected procedure wrapper
>      lock the PO
>      execute the protected procedure body
>      call System.Tasking.Protected_Objects.Single_Entry.Service_Entry (PO)
>         if there is a blocked entry call then
>            if the barrier has become open then
>               execute the entry body IN THE ISR CONTEXT
>               unlock the PO
>               wakeup the entry's caller
>            else
>               unlock the PO
>            end if
>         else
>            unlock the PO
>         end if
>         return
>      return from interrupt
>
> I was more concerned that there may be (non-Ada, perhaps) restrictions
> on what can be done in an interrupt context. An example of such a
> restriction (admittedly not one I'd hope to see an entry body coming
> across) is that FreeRTOS has some API calls that MUST NOT be made from a
> task context and have a version that MUST ONLY be called from an
> interrupt context.

I see. Your point is that GNAT is buggy and that's likely to cause problems 
in some obscure and non-reproducible cases.

But this has nothing to do with the language. Just because there is a 
permission to do something (use some other task to execute an entry body) 
does not mean that it should be used, especially if that is potentially 
causing problems.

Of course, this may not really be a problem in practice because of something 
that happens elsewhere. (Perhaps there is some different flow in the case of 
an ISR - I really would not expect them to work the same as a regular call.)

                                   Randy. 

Re: Protected handlers & entry bodies

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> I see. Your point is that GNAT is buggy and that's likely to cause problems 
> in some obscure and non-reproducible cases.
>
> But this has nothing to do with the language. Just because there is a 
> permission to do something (use some other task to execute an entry body) 
> does not mean that it should be used, especially if that is potentially 
> causing problems.

Not sure that GNAT's actually buggy. Re-reading C.3.1(17):

   When the aspects Attach_Handler or Interrupt_Handler are specified
   for a protected procedure, the implementation is allowed to impose
   implementation-defined restrictions on the corresponding
   protected_type_declaration and protected_body.

it seems to me it'd be fair to claim that restrictions could be imposed
on entry bodies. With my current implementation, one such would be to
disallow the use of Ada.Real_Time.Clock!

Re: Protected handlers & entry bodies

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lyh9vlnk8v.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> I see. Your point is that GNAT is buggy and that's likely to cause 
>> problems
>> in some obscure and non-reproducible cases.
>>
>> But this has nothing to do with the language. Just because there is a
>> permission to do something (use some other task to execute an entry body)
>> does not mean that it should be used, especially if that is potentially
>> causing problems.
>
> Not sure that GNAT's actually buggy. Re-reading C.3.1(17):
>
>   When the aspects Attach_Handler or Interrupt_Handler are specified
>   for a protected procedure, the implementation is allowed to impose
>   implementation-defined restrictions on the corresponding
>   protected_type_declaration and protected_body.
>
> it seems to me it'd be fair to claim that restrictions could be imposed
> on entry bodies. With my current implementation, one such would be to
> disallow the use of Ada.Real_Time.Clock!

Good point. I read that too quickly and confused protected_body with 
subprogram_body.

                     Randy.