Issue 3457: Definition of "the_priority" ambiguous and incomplete (rt-corba-ftf) Source: Objective Interface Systems (Mr. Bill Beckwith, r.william.beckwith(at)ois.com) Nature: Uncategorized Issue Severity: Summary: The specification implies but does not clearly state that the "the_priority" attribute of the RTCORBA::Current local interface should set and get the base priority of the thread. I suggest that the following three modifications to the specification: 1. change the name of the "the_priority" attribute to "base_priority"; 2. add another priority attribute to RTCORBA::Current called "active_priority"; and 3. replace the second paragraph in section 4.6 which currently reads: A Real-Time CORBA Priority may be associated with the current thread, by setting the priority attribute of the RTCORBA::Current object: with: There are two views of CORBA priority for a given thread: the base priority and• the active priority. The base priority is the priority that application code explicitly sets. The active priority is the priority the thread is currently running at. Note that the active priority may temporarily be higher than the base priority because of temporary priority boosts caused by either the ORB's or the O/S's resource protection mechanisms. There are two attributes in the RTCORBA::Current interface for setting and getting these two views of priority: Resolution: accepted Revised Text: Resolution: Change the priority attribute's name from 'the_priority' to 'base_priority'. Change the second paragraph on page 35 from "As a consequence of setting this attribute,a Real-Time ORB shall set the base native thread priority to the value determined by calling PriorityMapping:: to_native before returning from the set attribute call" to "When the attribute is set to a valid Real-Time CORBA Priority value, the value is immediately used to set the base native priority of the thread. The native priority value to use is determined by calling PriorityMapping::to_native on the installed PriorityMapping. The native thread priority shall be set before the set attribute call returns." And add this paragraph at the end of section 4.6 : "Retrieving the value of this attribute returns the last value that was set from the current thread. If this attribute has not previously been set for the current thread, attempting to retrieve the value causes an INITIALIZE System Exception to be raised." Actions taken: March 23, 2000: received issue January 9, 2001: closed issue Discussion: End of Annotations:===== X-Sender: beckwb@192.84.85.3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 23 Mar 2000 18:18:58 -0500 To: rt-corba-ftf@omg.org From: Bill Beckwith Subject: Definition of "the_priority" ambiguous and incomplete Cc: issues@omg.org Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id TAA07175 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: D^J!!h(9e9pmMe9c& Organization: Highlander X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Beckwith CC: rt-corba-ftf@omg.org, jon@highlander.com, jorge@highlander.com, ken@highlander.com Subject: Re: Definition of "the_priority" ambiguous and incomplete References: <4.2.0.58.20000323180411.00a78d30@192.84.85.3> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: ^l7!!%"4e9CcGe9;:>!! Bill Beckwith wrote: > The specification implies but does not clearly state that > the "the_priority" attribute of the RTCORBA::Current local > interface should set and get the base priority of the thread. > > I suggest that the following three modifications to the > specification: > > 1. change the name of the "the_priority" attribute to > "base_priority"; > > 2. add another priority attribute to RTCORBA::Current called > "active_priority"; and > > 3. replace the second paragraph in section 4.6 which currently > reads: > > A Real-Time CORBA Priority may be associated with > the current thread, by setting the priority attribute > of the RTCORBA::Current object: > > with: > > There are two views of CORBA priority for a given thread: > the base priority and the active priority. > > The base priority is the priority that application code > explicitly sets. The active priority is the priority the > thread is currently running at. Note that the active > priority may temporarily be higher than the base priority > because of temporary priority boosts caused by either the > ORB's or the O/S's resource protection mechanisms. > > There are two attributes in the RTCORBA::Current interface > for setting and getting these two views of priority: > > -- Bill Bill Your proposal as it stands goes beyond clarification. Having an attribute for active priority (which would have to be readonly, I think) as well as for the base priority is something we discussed at length in submitters meetings, and it didn't make it into the final submission. Some submitters were strongly opposed to exposing the active priority to the application. How about a compromise : stick with one attribute, that gets and sets the base priority, but beef up the wording to make it clear that it is the base priority that is being manipulated. (And explaing the relationship to the active priority.) As for the name of the attribute, we originally went with 'priority', and moved to 'the_priority' at the last moment, because of the IDL rules about conflicting tokens ( RTCORBA::Priority and this attribute if named 'priority'). Personally I dislike the name 'the_priority' .. but I also dislike 'base_priority' (even more, actually.) How about 'rtcorba_priority'? Jon. X-Sender: beckwb@192.84.85.3 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 27 Apr 2000 01:09:57 -0400 To: Jon Currey From: Bill Beckwith Subject: Re: Definition of "the_priority" ambiguous and incomplete Cc: rt-corba-ftf@omg.org In-Reply-To: <3907497B.A91F01F1@highlander.com> References: <4.2.0.58.20000323180411.00a78d30@192.84.85.3> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: gb~e994,e91X5e9F1nd9 At 03:54 PM 4/26/00, Jon Currey wrote: > >Your proposal as it stands goes beyond clarification. Having an attribute for >active priority (which would have to be readonly, I think) as well as for >the base priority is something we discussed at length in submitters meetings, >and it didn't make it into the final submission. Some submitters were >strongly opposed to exposing the active priority to the application. I remember that one submitter objected to specifying whether base or active priority was passed in the service context. The topic I've addressed in my issue never discussed. Also, all of the submitters are part of this FTF so any objections to clarifying active v.s. base priorities should be brought forward here. >How about a compromise : stick with one attribute, that gets and sets the >base priority, but beef up the wording to make it clear that it is the base >priority that is being manipulated. (And explaing the relationship to the >active priority.) > >As for the name of the attribute, we originally went with 'priority', and moved >to 'the_priority' at the last moment, because of the IDL rules about >conflicting tokens ( RTCORBA::Priority and this attribute if named 'priority'). > >Personally I dislike the name 'the_priority' .. but I also dislike >'base_priority' > >(even more, actually.) How about 'rtcorba_priority'? You comments don't addresses the core issue of allowing user's to get the active priority. Remember that no RTOS that I know of allows you access to the base priority. All only allow access to the active priority. -- Bill Sender: jon Message-ID: <390E55F9.6E2E9143@highlander.com> Date: Tue, 02 May 2000 00:13:45 -0400 From: Jon Currey Organization: Highlander X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bill Beckwith , rt-corba-ftf@omg.org Subject: Re: Definition of "the_priority" ambiguous and incomplete References: <4.2.0.58.20000323180411.00a78d30@192.84.85.3> <4.3.1.2.20000427010406.00b1d5d0@192.84.85.3> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: li@e9Z7R!!Gbc!!Y)Wd9 Bill Beckwith wrote: > > At 03:54 PM 4/26/00, Jon Currey wrote: > > > >Your proposal as it stands goes beyond clarification. Having an attribute for > >active priority (which would have to be readonly, I think) as well as for > >the base priority is something we discussed at length in submitters meetings, > >and it didn't make it into the final submission. Some submitters were > >strongly opposed to exposing the active priority to the application. > > I remember that one submitter objected to specifying whether base or > active priority was passed in the service context. The topic I've > addressed in my issue never discussed. Reasons for not standardizing an API for active priority : - No reason has been given why the user needs a RT CORBA API for reading the active (i.e. actual) thread priority in addition to the base (i.e. application-set) priority. . RT CORBA 1.0 is supporting fixed-priority scheduling. In this, we have included mandatory support for priority inheritance, which is what creates the potential for an active priority that is different from the base priority. This does not imply that the application needs to be able to read the active priority to achieve this style of scheduling. . Without an understood need, it is better to keep the (standardized) API as simple as possible. Having only one priority value to deal with is significantly more straightforward for RT CORBA users than having two. - The active priority attribute may not always be readable (via an RT CORBA API.) . The (base) priority attribute is a RTCORBA::Priority value, that is then mapped to a Native Priority value via the installed RTCORBA::PriorityMapping. . Any priority attribute of RTCORBA::Current should be a RTCORBA::Priority value, rather than a Native Priority value. If an active priority attribute were introduced, it should be a RTCORBA::Priority value as well. . If priority inheritance is being delivered by the RTOS rather than the RT CORBA run-time (either approach being allowed, as an implementation choice), the active priority produced as a result of priority inheritance is not guaranteed to be mappable back to a RTCORBA::Priority value using the installed RTCORBA::PriorityMapping. The attribute get operation will have to throw an exception in this case. . The active priority will always be readable as a native priority, via the native RTOS thread priority API. - It is not clear what semantics could be given to the active_priority attribute's set operation. . What would it mean for the application to change the active priority as opposed to the base priority? Would changing the active priority change the base priority too? . Or is the active_priority attribute meant to be readonly? > > Also, all of the submitters are part of this FTF so any objections > to clarifying active v.s. base priorities should be brought forward > here. I have no objection to clarifying the distinction between base and active priority. The terms are introduced in section 4.3 (pages 29-31 in ptc/99-06-02), but we could certainly duplicate, move or add cross-references to some of this text in section 4.6 on Real-Time CORBA Current. However, your proposal is not just to clarify the distinction, but to extend the priority API to provide the application with access to the active priority as a Real-Time CORBA Priority value. Before doing this, I would like to understand what deficiency not having this API causes (or, conversely, what benefit adding it brings.) Can you give us a concrete example Bill? In the mean time, I have an alternative proposal : Change the priority attribute's name from 'the_priority' to 'rtcorba_priority'. Change the second paragraph on page 35 from "As a consequence of setting this attribute,a Real-Time ORB shall set the base native thread priority to the value determined by calling PriorityMapping::to_native before returning from the set attribute call" to "When the attribute is set to a valid Real-Time CORBA Priority value, the value is immediately used to set the base native priority of the thread. The native priority value to use is determined by calling PriorityMapping::to_natove on the installed PriorityMapping. The native thread priority shall be set before the set attribute call returns." Jon. Sender: jon Message-ID: <391053AF.446E5C0E@highlander.com> Date: Wed, 03 May 2000 12:28:31 -0400 From: Jon Currey Organization: Highlander X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bill Beckwith CC: rt-corba-ftf@omg.org Subject: Re: Definition of "the_priority" ambiguous and incomplete References: <4.2.0.58.20000323180411.00a78d30@192.84.85.3> <4.3.1.2.20000427010406.00b1d5d0@192.84.85.3> <390E55F9.6E2E9143@highlander.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: od2e9PMQe97_Le9H)T!! Bill I still have the same concerns about this proposal : - We haven't been presented with a reason that the Real-Time CORBA API needs to provide the application programmer with the active priority as a RTCORBA::Priority value. . The base priority seems to be adequate for achieving fixed priority scheduling with priority inheritance. - The active priority is, as you point out, always available through a native OS call . This makes the priority available as a native priority, rather than a RTCORBA::Priority, but the application can always use the installed priority mapping to obtain this as a RTCORBA::Priority. - The active priority may not be mappable back to RTCORBA::Priority, depending on the priority mapping installed. - The proposal as stands doesn't say that the new active_priority attribute is readonly, therefore I think we have to assume is is not readonly. In which case, the semantics for setting of the active priority are undefined. Unless you can provide us a use case that demonstrates the need for active_priority to be accessible through the RT CORBA API (and fix the 'readonly' issue), I will continue to suggest that we do not vote to accept this proposal. Jon. Jon Currey wrote: > > Bill Beckwith wrote: > > > > At 03:54 PM 4/26/00, Jon Currey wrote: > > > > > >Your proposal as it stands goes beyond clarification. Having an attribute for > > >active priority (which would have to be readonly, I think) as well as for > > >the base priority is something we discussed at length in submitters meetings, > > >and it didn't make it into the final submission. Some submitters were > > >strongly opposed to exposing the active priority to the application. > > > > I remember that one submitter objected to specifying whether base or > > active priority was passed in the service context. The topic I've > > addressed in my issue never discussed. > > Reasons for not standardizing an API for active priority : > > - No reason has been given why the user needs a RT CORBA API for reading the active (i.e. > actual) thread priority in addition to the base (i.e. application-set) priority. > . RT CORBA 1.0 is supporting fixed-priority scheduling. In this, we have included > mandatory support for priority inheritance, which is what creates the potential for an > active priority that is different from the base priority. This does not imply that the > application needs to be able to read the active priority to achieve this style of scheduling. > . Without an understood need, it is better to keep the (standardized) API as simple as possible. > Having only one priority value to deal with is significantly more straightforward for > RT CORBA users than having two. > > - The active priority attribute may not always be readable (via an RT CORBA API.) > . The (base) priority attribute is a RTCORBA::Priority value, that is then mapped to a > Native Priority value via the installed RTCORBA::PriorityMapping. > . Any priority attribute of RTCORBA::Current should be a RTCORBA::Priority value, rather > than a Native Priority value. If an active priority attribute were introduced, it should be a > RTCORBA::Priority value as well. > . If priority inheritance is being delivered by the RTOS rather than the RT CORBA > run-time (either approach being allowed, as an implementation choice), the active priority > produced as a result of priority inheritance is not guaranteed to be mappable back to > a RTCORBA::Priority value using the installed RTCORBA::PriorityMapping. The attribute > get operation will have to throw an exception in this case. > . The active priority will always be readable as a native priority, via the > native RTOS thread priority API. > > - It is not clear what semantics could be given to the active_priority attribute's set > operation. > . What would it mean for the application to change the active priority as opposed > to the base priority? Would changing the active priority change the base priority too? > . Or is the active_priority attribute meant to be readonly? > > > > > Also, all of the submitters are part of this FTF so any objections > > to clarifying active v.s. base priorities should be brought forward > > here. > > I have no objection to clarifying the distinction between base and active priority. The terms > are introduced in section 4.3 (pages 29-31 in ptc/99-06-02), but we could certainly > duplicate, move or add cross-references to some of this text in section 4.6 on > Real-Time CORBA Current. > > However, your proposal is not just to clarify the distinction, but to extend the priority API > to provide the application with access to the active priority as a Real-Time CORBA Priority value. > Before doing this, I would like to understand what deficiency not having this API causes (or, > conversely, what benefit adding it brings.) Can you give us a concrete example Bill? > > In the mean time, I have an alternative proposal : > Change the priority attribute's name from 'the_priority' to 'rtcorba_priority'. > Change the second paragraph on page 35 from > "As a consequence of setting this attribute,a Real-Time ORB shall set the base native > thread priority to the value determined by calling PriorityMapping::to_native before > returning from the set attribute call" > to > "When the attribute is set to a valid Real-Time CORBA Priority value, the value is immediately > used to set the base native priority of the thread. The native priority value to use is > determined by calling PriorityMapping::to_natove on the installed PriorityMapping. The native > thread priority shall be set before the set attribute call returns." > > Jon. X-Sender: beckwb@192.84.85.3 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 03 May 2000 18:37:06 -0400 To: Jon Currey , rt-corba-ftf@omg.org From: Bill Beckwith Subject: Re: [Fwd: Definition of "the_priority" ambiguous and incomplete] In-Reply-To: <390F4C3C.DFF5BB56@highlander.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: J,[d9_("e9c)#e9Glb!! [I'm at home sick today and as I mentioned the phone lines to my neighborhood were cut. So you've gotten this because they've fixed the wires.] At 05:44 PM 5/2/00, you wrote: > >Are you going to be able to mail out a use case for >active_priority overnight? We need to start voting tomorrow, and >I'm reluctant to add this to the spec without understanding its >purpose. This issue I proposed with the resolution as stated resolves several problems with the current CORBA spec. No RTOS support for base priority --------------------------------- I am know aware of any RTOS that allows one to manipulate base priority as defined in the specification. RTOS'es only allow for the manipulation of the current, active priority of a thread. This means that the semantics of setting the "the_priority" attribute are murky at best. The resolution I proposed makes the semantics stated in the existing specification for active and base priority correct and clear. No way for users to access active priority ------------------------------------------ There is no current method for users to get to the current CORBA priority of a thread. If a user calls This means that users can not use the CORBA priority to order queues in their application by active priority. This forces application developers to make poor decisions in their applications. The resolution I proposed allows users to get both the base and active priority of a thread. >Also, do you accept the point about it being a readonly attribute? No, see below. >Your proposal needs to be updated either to reflect this, or to >explain the semantics of changing the active priority. The problem with making it a readonly attribute is that it does not provide a consistent interface to the scheduling service implementations for manipulating active priority. Well behaved user applications won't need to set the active priority. >Date: Tue, 02 May 2000 00:13:45 -0400 >From: Jon Currey >To: Bill Beckwith , rt-corba-ftf@omg.org >Subject: Re: Definition of "the_priority" ambiguous and incomplete > >Bill Beckwith wrote: >> >> At 03:54 PM 4/26/00, Jon Currey wrote: >> > >> >Your proposal as it stands goes beyond clarification. Having >> >an attribute for active priority (which would have to be >> >readonly, I think) as well as for the base priority is >> >something we discussed at length in submitters meetings, and >> >it didn't make it into the final submission. Some submitters >> >were strongly opposed to exposing the active priority to the >> >application. >> >> I remember that one submitter objected to specifying whether >> base or active priority was passed in the service context. >> The topic I've addressed in my issue never discussed. > >Reasons for not standardizing an API for active priority : > > - No reason has been given why the user needs a RT CORBA API for >reading >the active (i.e. >actual) thread priority in addition to the base >(i.e. application-set) >priority. > . RT CORBA 1.0 is supporting fixed-priority scheduling. In > this, we have included mandatory support for priority > inheritance, which is what creates the potential for an > active priority that is different from the base priority. > This does not imply that the application needs to be able to > read the active priority to achieve this style of scheduling. You are wrong about this. Applications can and should make decisions in their code based on active priority. Otherwise the application will increasing priority inversions and potential contributing to possible priority deadlock situations. > . Without an understood need, it is better to keep the > (standardized) API as simple as possible. Having only one > priority value to deal with is significantly more > straightforward for RT CORBA users than having two. The needs are well understood by the domain and are explained above. > - The active priority attribute may not always be readable > (via an RT CORBA API.) The point is that it should always be readable by the RT CORBA API. > . The (base) priority attribute is a RTCORBA::Priority > value, that is then mapped to a Native Priority value via > the installed RTCORBA::PriorityMapping. Check. > . Any priority attribute of RTCORBA::Current should be a > RTCORBA::Priority value, rather than a Native Priority > value. If an active priority attribute were introduced, it > should be a RTCORBA::Priority value as well. > . If priority inheritance is being delivered by the RTOS > rather than the RT CORBA run-time (either approach being > allowed, as an implementation choice), the active priority > produced as a result of priority inheritance is not > guaranteed to be mappable back to a RTCORBA::Priority value > using the installed RTCORBA::PriorityMapping. The attribute > get operation will have to throw an exception in this case. I believe this is incorrect. The RTOS priority is always the active priority. The base priority is the one that is not accessible. > . The active priority will always be readable as a native > priority, via the native RTOS thread priority API. Hmmm. This is in conflict with your previous bullet. Yes the active _native_ priority is accessible via direct calls to the RTOS. But the active _CORBA_ priority is never available to the user in the existing specification. > - It is not clear what semantics could be given to the > active_priority attribute's set operation. You might want to re-read the proposed resolution. > . What would it mean for the application to change the > active priority as opposed to the base priority? Would > changing the active priority change the base priority too? Applications would not typically do this. Scheduling services would. > . Or is the active_priority attribute meant to be readonly? No, see above. >> Also, all of the submitters are part of this FTF so any objections >> to clarifying active v.s. base priorities should be brought >> forward >> here. > >I have no objection to clarifying the distinction between base >and active priority. The terms are introduced in section 4.3 >(pages 29-31 in ptc/99-06-02), but we could certainly duplicate, >move or add cross-references to some of this text in section 4.6 >on Real-Time CORBA Current. The existing base and active priority definitions work just fine with the proposed resolution. They need re-writing if this issue doesn't pass. >However, your proposal is not just to clarify the distinction, >but to extend the priority API to provide the application with >access to the active priority as a Real-Time CORBA Priority >value. Before doing this, I would like to understand what >deficiency not having this API causes (or, conversely, what >benefit adding it brings.) Can you give us a concrete example >Bill? See above. >In the mean time, I have an alternative proposal : >Change the priority attribute's name from 'the_priority' to >'rtcorba_priority'. This fixes no problems but gets rid of the dorky name. >Change the second paragraph on page 35 from >"As a consequence of setting this attribute,a Real-Time ORB >shall set the base native thread priority to the value >determined by calling PriorityMapping::to_native before >returning from the set attribute call" >to >"When the attribute is set to a valid Real-Time CORBA Priority >value, the value is immediately used to set the base native >priority of the thread. The native priority value to use is >determined by calling PriorityMapping::to_natove on the >installed PriorityMapping. The native thread priority shall be >set before the set attribute call returns." You've set this attribute up to get the base priority and set the active priority. This is even worse. Thus I don't accept this as a alternative resolution to one proposed in the issue. -- Bill Sender: jon Message-ID: <3975DD59.98A34008@highlander.com> Date: Wed, 19 Jul 2000 12:54:49 -0400 From: Jon Currey Organization: Highlander X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "rt-corba-ftf@omg.org" Subject: Proposal for Issue 3457 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: /-!!!g((!!(OZ!!^C7!! Issue 3457: Definition of "the_priority" ambiguous and incomplete Summary: The specification implies but does not clearly state that the "the_priority" attribute of the RTCORBA::Current local interface should set and get the base priority of the thread. The following proposal was made when the issue was submitted : Proposed Resolution: It is suggested that the following three modifications be made to the specification: 1. change the name of the "the_priority" attribute to "base_priority"; 2. add another priorityattribute to RTCORBA::Current called "active_priority"; 3. replace the second paragraph in section 4.6 which currently reads: A Real-Time CORBA Priority may be associated with the current thread, by setting the priority attribute of the RTCORBA::Current object: with: There are two views of CORBA priority for a given thread: the base priority and the active priority. The base priority is the priority that application code explicitly sets. The active priority is the priority the thread is currently running at. Note that the active priority may temporarily be higher than the base priority because of temporary priority boosts caused by either the ORB's or the O/S's resource protection mechanisms. There are two attributes in the RTCORBA::Current interface for setting and getting these two views of priority: I would like to make an alternative proposal. (Lets call the above proposal 'Proposal A', and my new one 'Proposal B'.) Proposal B: Change the priority attribute's name from 'the_priority' to 'rtcorba_priority'. Change the second paragraph on page 35 from "As a consequence of setting this attribute,a Real-Time ORB shall set the base native thread priority to the value determined by calling PriorityMapping::to_native before returning from the set attribute call" to "When the attribute is set to a valid Real-Time CORBA Priority value, the value is immediately used to set the base native priority of the thread. The native priority value to use is determined by calling PriorityMapping::to_native on the installed PriorityMapping. The native thread priority shall be set before the set attribute call returns." And add this paragraph at the end of section 4.6 : "Retrieving the value of this attribute returns the last value that was set from the current thread. If a Real-Time CORBA Priority value has not previously been set for the current thread, attempting to retrieve the value causes an INITIALIZE System Exception to be raised." The reasons for my proposal are : I disagree with the assertion that the current wording of the spec does not make it clear that setting this attribute sets the base priority of the thread. However, I think that it improves the wording by making it clear that the change is made immediately (i.e. before the call returns.) I agree that the current wording of the spec does not make it clear what getting the value of this attribute returns. This is addressed by the new final paragraph. I don't see how it follows from this issue of clarification that we need to extend the interface (and hence change the RT CORBA programming model) to expose the active priority as well as the base priority. I am quite happy with the present model, where the application only needs to know about the base priority, as a Real-Time CORBA value. The name change from 'the_priority' to 'rtcorba_priority' is basically aesthetic. We originally called it 'priority', but encountered the issue of name conflict in IDL (with the RTCORTBA::Priority type). Jon. Sender: jon Message-ID: <3978B4C4.87CD8395@highlander.com> Date: Fri, 21 Jul 2000 16:38:28 -0400 From: Jon Currey Organization: Highlander X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "rt-corba-ftf@omg.org" CC: Bill Beckwith Subject: Re: Proposal for Issue 3457 References: <3975DD59.98A34008@highlander.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ? > Issue 3457: Definition of "the_priority" ambiguous and incomplete > > Summary: The specification implies but does not clearly state that the > "the_priority" attribute of the RTCORBA::Current local interface should set > and get the base priority of the thread. > > The following proposal was made when the issue was submitted : > > Proposed Resolution: It is suggested that the following three modifications > be made to the specification: > > 1. change the name of the "the_priority" attribute to "base_priority"; > 2. add another priorityattribute to RTCORBA::Current called "active_priority"; > 3. replace the second paragraph in section 4.6 which currently reads: > > A Real-Time CORBA Priority may be associated with the current thread, by setting > the priority attribute of the RTCORBA::Current object: > > with: > > There are two views of CORBA priority for a given thread: the base priority and > the active priority. The base priority is the priority that application code > explicitly sets. The active priority is the priority the thread is currently > running at. Note that the active priority may temporarily be higher than the > base priority because of temporary priority boosts caused by either the ORB's > or the O/S's resource protection mechanisms. There are two attributes in the > RTCORBA::Current interface for setting and getting these two views of priority: > > I would like to make an alternative proposal. (Lets call the above proposal > 'Proposal A', and my new one 'Proposal B'.) > > Proposal B: Change the priority attribute's name from 'the_priority' to > 'rtcorba_priority'. Change the second paragraph on page 35 from > > "As a consequence of setting this attribute,a Real-Time ORB shall set the base native > thread priority to the value determined by calling PriorityMapping::to_native before > returning from the set attribute call" > to > "When the attribute is set to a valid Real-Time CORBA Priority value, the value is immediately > used to set the base native priority of the thread. The native priority value to use is > determined by calling PriorityMapping::to_native on the installed PriorityMapping. The native > thread priority shall be set before the set attribute call returns." > > And add this paragraph at the end of section 4.6 : > > "Retrieving the value of this attribute returns the last value that was set from the > current thread. If a Real-Time CORBA Priority value has not previously been set for > the current thread, attempting to retrieve the value causes an INITIALIZE System > Exception to be raised." > > The reasons for my proposal are : > > I disagree with the assertion that the current wording of the spec does not > make it clear that setting this attribute sets the base priority of the thread. > However, I think that it improves the wording by making it clear that the change > is made immediately (i.e. before the call returns.) > > I agree that the current wording of the spec does not make it clear what getting > the value of this attribute returns. This is addressed by the new final paragraph. > > I don't see how it follows from this issue of clarification that we need to > extend the interface (and hence change the RT CORBA programming model) to expose > the active priority as well as the base priority. I am quite happy with the > present model, where the application only needs to know about the base priority, > as a Real-Time CORBA value. > > The name change from 'the_priority' to 'rtcorba_priority' is basically aesthetic. > We originally called it 'priority', but encountered the issue of name conflict > in IDL (with the RTCORTBA::Priority type). > > Jon.