!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). ***************************************************************