Version 1.1 of acs/ac-00228.txt

Unformatted version of acs/ac-00228.txt version 1.1
Other versions for file acs/ac-00228.txt

!standard D.3(6.1/3)          12-02-11 AC95-00228/00
!class confirmation 12-02-11
!status received no action 12-02-10
!status received 12-02-07
!subject
!summary
!appendix

From: Jean-Pierre Rosen
Sent: Tuesday, February  7, 2012  1:50 AM

[He's responding to earlier private discussion on his review - Editor.]

>> D.3(6.1/3)
>> (This is not part of the changed text, but it seems plain wrong)
>>    The expression specified for the Priority or Interrupt_Priority
>>    aspect (see D.1) is evaluated as part of the creation of the
>>    corresponding protected object and converted to the subtype
>>    System.[Any_]Priority or System.[Interrupt]{Any}_Priority,
>>    respectively.
>
> Maybe it is "plain wrong", but it has been true of pragmas Priority
> and Interrupt_Priority for protected objects since Ada 95 (note that
> this wording was moved from paragraph 9, and I checked this wording
> in my Chris Anderson presentation copy of the Ada 95 standard, it's
> definitely original Ada 95 wording). And as such, I have to think it
> is intentional. Moreover, changing it now would be a significant
> compatibility problem (making interrupt priorities raise an
> exception when given in pragma Priority, when they never did that in
> the past). So I dare not make such a change.
>
> If you still think this is "plain wrong", feel free to bring it to
> the entire group for discussion. I'd expect Robert to complain that
> changing it would be a gratuitous incompatibility, but you never know.

As formulated, it means that if you give a pragma Priority with a
value in Interrupt_Priority, it does not raise Constraint_Error, and
if you give a pragma Interrupt_Priority with a value in Priority, it
raises Constraint_Error!

I don't think it would be a gratuitous incompatibility, because
hopefully compilers didn't notice the error and implemented it as it
should be.

***************************************************************

From: Randy Brukardt
Sent: Tuesday, February  7, 2012  2:39 AM

It strikes me that that actually makes some sense, because the semantics of a
Ceiling Priority (which is what a PO takes) and that of a task priority are
essentially opposite of each other. That is, if a PO is going to run at
interrupt priority, it had never be set below such a priority (otherwise no
interrupt could even reach it), while with a task, it doesn't matter because it
could still be raised by calling an appropriate PO. (I'm ignoring dynamic
changes for this discussion.)

***************************************************************

From: Tucker Taft
Sent: Tuesday, February  7, 2012  2:12 PM

About a year ago I fixed our implementation to match the standard in this area:

r28267 | stt | 2011-02-22 16:12:29 -0500 (Tue, 22 Feb 2011) | 3 lines

Still build 4.004; the allowed range for a pragma Priority on a protected type
is Any_Priority (unlike on a task).

------------------------------------------------------------------------
r28266 | stt | 2011-02-22 14:58:55 -0500 (Tue, 22 Feb 2011) | 5 lines

Build 4.004.  Start enforcing C.3.1(11) and D.3 having to do with setting
Interrupt_Priority for a protected type, possibly with interrupt handlers.
Problem found by XXX customer. Add a "Ceiling_Check" check for suppress.

--------

Our lack of adherence to the standard was noticed by a customer.
I studied the rules when I received this complaint, and convinced myself they
made sense.  For a protected object, a typical reason to specify
"Interrupt_Priority" is because you want to use it as an interrupt handler, and
it would be an error to specify a priority that is below the interrupt level.
For a task, you use Interrupt_Priority if you want to indicate the task *might*
be running on an interrupt priority, but it is not an error if it isn't (or so
goes the reasoning).  For a protected object pragma Priority has no limitations
as far as setting the ceiling, whereas for a task object, pragma Priority can
only specify a priority in the non-interrupt range.

It all makes sense, at least given one world view.  And I agree the difference
was intentional (even if misguided in retrospect), and changing it now would be
incompatible, at least with our customer's expectations.

***************************************************************

From: Randy Brukardt
Sent: Tuesday, February  7, 2012  2:30 PM

...
> Our lack of adherence to the standard was noticed by a customer.
> I studied the rules when I received this complaint, and convinced
> myself they made sense.  For a protected object, a typical reason to
> specify "Interrupt_Priority" is because you want to use it as an
> interrupt handler, and it would be an error to specify a priority that
> is below the interrupt level.  For a task, you use Interrupt_Priority
> if you want to indicate the task *might* be running on an interrupt
> priority, but it is not an error if it isn't (or so goes the
> reasoning).  For a protected object pragma Priority has no limitations
> as far as setting the ceiling, whereas for a task object, pragma
> Priority can only specify a priority in the non-interrupt range.

Thanks for saying what I was trying to explain more clearly. Maybe the easiest
way to see this is to remember that a protected object is usable for all
priorities BELOW the given priorities, while a task is usable for all priorities
ABOVE the given priorities. Thus, if you want these to handle interrupts, the
range of priorities expected is different.

> It all makes sense, at least given one world view.  And I agree the
> difference was intentional (even if misguided in retrospect), and
> changing it now would be incompatible, at least with our customer's
> expectations.

While I doubt that the difference comes up often in practice, simply having one
example of a real-world incompatibility is enough to sink any change here. And
having someone care enough to get their vendor to change this means it was
important to someone!

***************************************************************

From: Alan Burns
Sent: Wednesday, February  8, 2012  2:48 AM

There was a long discussion on this years ago in pre Ada 95 days - I'm sure
people are too busy to care, so I'll not try and recreate it!

***************************************************************

From: Jean-Pierre Rosen
Sent: Wednesday, February  8, 2012  3:13 AM

Fine. If it is a deliberate choice by the real-time community, it closes the
discussion.

(Aside: now that I see the issue, I think that PO priorities should have used a
different pragma name than task priorities. But before anyone screams, yes it is
WAAAAYYYY too late).

***************************************************************


Questions? Ask the ACAA Technical Agent