Issue 3339: ref counting ambiguous? (cxx_revision) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com) Nature: Uncategorized Issue Severity: Summary: For servant reference counting, the words "at least once" appear in a number of places when it comes to servant activation. set_servant(), activate_object(), activate_object_with_id(), servant_to_id(), servant_to_reference(), and _this() all use this language (pages 1-137 and 1-138): ... will invoke _add_ref at least once on the Servant argument... Problem: suppose my ORB calls _add_ref() twice in each of these operations for some reason. I now have a problem. That's because, for servant activators, responsibility for calling _remove_ref() passes to etherialize(). However, if the ORB is permitted to call _add_ref() as many times as it likes, I have no idea how many times I have to call _remove_ref() from within etherealize(). I think that the spec should say that _add_ref() is called *exactly* once for these operations *if* the corresponding servant is not in the AOM already. I vaguely remember the discussion about optimization of the calls to _add_ref() and _remove_ref(). I think the idea was to permit the ORB to avoid redundant calls. However, it seems that the language in the spec isn't precise enough. Under one interpretation, the refcount counts the number of entries in the AOM. Under another interpretation, it counts the number of calls in progress as well (because an ORB could call _add_ref() when a call is dispatched and call _remove_ref() when it finishes). Under yet a third interpretation, the refcount counts the number of object references in my address space. That interpretation is happens if *every* call to _this() calls _add_ref()... The language is not precise enough, I think... Resolution: Revised Text: Actions taken: March 3, 2000: received issue Discussion: deferred in June 2011 to the next RTF End of Annotations:===== Date: Fri, 3 Mar 2000 15:29:16 +1000 (EST) From: Michi Henning Reply-To: C++ Revision Task Force To: C++ Revision Task Force cc: issues@omg.org Subject: ref counting ambiguous? Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Aeid9UC(e9ok_!!g(Q!! For servant reference counting, the words "at least once" appear in a number of places when it comes to servant activation. set_servant(), activate_object(), activate_object_with_id(), servant_to_id(), servant_to_reference(), and _this() all use this language (pages 1-137 and 1-138): ... will invoke _add_ref at least once on the Servant argument... Problem: suppose my ORB calls _add_ref() twice in each of these operations for some reason. I now have a problem. That's because, for servant activators, responsibility for calling _remove_ref() passes to etherialize(). However, if the ORB is permitted to call _add_ref() as many times as it likes, I have no idea how many times I have to call _remove_ref() from within etherealize(). I think that the spec should say that _add_ref() is called *exactly* once for these operations *if* the corresponding servant is not in the AOM already. I vaguely remember the discussion about optimization of the calls to _add_ref() and _remove_ref(). I think the idea was to permit the ORB to avoid redundant calls. However, it seems that the language in the spec isn't precise enough. Under one interpretation, the refcount counts the number of entries in the AOM. Under another interpretation, it counts the number of calls in progress as well (because an ORB could call _add_ref() when a call is dispatched and call _remove_ref() when it finishes). Under yet a third interpretation, the refcount counts the number of object references in my address space. That interpretation is happens if *every* call to _this() calls _add_ref()... The language is not precise enough, I think... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: "'C++ Revision Task Force'" Subject: RE: ref counting ambiguous? Date: Fri, 3 Mar 2000 09:13:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: h08!!fS?e9?Ymd9Dd/e9 My recollection is that we were trying to give orb implementors latitude for their implementations. If they go through some recursive code and need to make extra increments to the reference count, then that should be ok. Basically, the orb should be able to do as many _add_refs as it wants, as long as it provides matching _remove_refs eventually, and doesn't remove all of its refs until it is done with the servant. But none of this should be of concern to the application developer. His contract regarding reference counting should be well defined. I agree that the existing words leave something to be desired in this regard. I think the best course may be to refine the words about the obligations of the user of the orb and the guarantees the orb makes to the user, but leave it to the orb to figure out what it needs to do. There are probably more words than needed now about how the orb must do this. Paul > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: Friday, March 03, 2000 12:29 AM > To: C++ Revision Task Force > Cc: issues@omg.org > Subject: ref counting ambiguous? > > > > For servant reference counting, the words "at least once" appear > in a number of places when it comes to servant activation. > set_servant(), > activate_object(), activate_object_with_id(), servant_to_id(), > servant_to_reference(), and _this() all use this language > (pages 1-137 and > 1-138): > > ... will invoke _add_ref at least once on the Servant > argument... > > Problem: suppose my ORB calls _add_ref() twice in each of > these operations > for some reason. I now have a problem. That's because, for servant > activators, responsibility for calling _remove_ref() passes to > etherialize(). However, if the ORB is permitted to call _add_ref() > as > many times as it likes, I have no idea how many times I have to call > _remove_ref() from within etherealize(). I think that the > spec should say > that _add_ref() is called *exactly* once for these operations *if* > the > corresponding servant is not in the AOM already. > > I vaguely remember the discussion about optimization of the calls > to _add_ref() and _remove_ref(). I think the idea was to > permit the ORB > to avoid redundant calls. However, it seems that the language > in the spec > isn't precise enough. Under one interpretation, the refcount counts > the number of entries in the AOM. Under another > interpretation, it counts > the number of calls in progress as well (because an ORB could > call _add_ref() > when a call is dispatched and call _remove_ref() when it finishes). > Under yet a third interpretation, the refcount counts the number of > object references in my address space. That interpretation is > happens > if *every* call to _this() calls _add_ref()... > > The language is not precise enough, I think... > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html > Sender: jon@corvette.floorboard.com Message-ID: <38BFE423.659085B4@floorboard.com> Date: Fri, 03 Mar 2000 08:11:15 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: C++ Revision Task Force Subject: Re: ref counting ambiguous? References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ?=Be9\>\d9lmk!!GBA!! Michi Henning wrote: > > For servant reference counting, the words "at least once" appear > in a number of places when it comes to servant > activation. set_servant(), > activate_object(), activate_object_with_id(), servant_to_id(), > servant_to_reference(), and _this() all use this language (pages > 1-137 and > 1-138): > > ... will invoke _add_ref at least once on the Servant > argument... > > Problem: suppose my ORB calls _add_ref() twice in each of these > operations > for some reason. I now have a problem. That's because, for servant > activators, responsibility for calling _remove_ref() passes to > etherialize(). However, if the ORB is permitted to call _add_ref() > as > many times as it likes, I have no idea how many times I have to call > _remove_ref() from within etherealize(). I think that the spec > should say > that _add_ref() is called *exactly* once for these operations *if* > the > corresponding servant is not in the AOM already. Perhaps the language isn't entirely clear, but the intent was to not prohibit the ORB from calling additional _add_ref()/_remove_ref() pairs above and beyond the one call to _add_ref() that is required. Certainly an ORB that called _add_ref() twice internally without calling _remove_ref() once internally would be broken. > I vaguely remember the discussion about optimization of the calls > to _add_ref() and _remove_ref(). I think the idea was to permit the > ORB > to avoid redundant calls. However, it seems that the language in the > spec > isn't precise enough. Under one interpretation, the refcount counts > the number of entries in the AOM. Under another interpretation, it > counts > the number of calls in progress as well (because an ORB could call > _add_ref() > when a call is dispatched and call _remove_ref() when it finishes). > Under yet a third interpretation, the refcount counts the number of > object references in my address space. That interpretation is > happens > if *every* call to _this() calls _add_ref()... The intent was to guarantee that the ORB called _add_ref() enough times to make sure that the servant was not prematurely deleted. Any ORB implementation strategy that guarantees that the ORB & POA hold the reference count high enough to prevent premature servant destruction and yet decrement it at the right time to allow for proper servant destruction should be allowed. > The language is not precise enough, I think... English isn't precise enough. Anyone for Loglan? :-) -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Sat, 4 Mar 2000 08:14:04 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: C++ Revision Task Force Subject: Re: ref counting ambiguous? In-Reply-To: <38BFE423.659085B4@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: #%^!!6Ba!!~l?e9i`4!! On Fri, 3 Mar 2000, Jonathan Biggar wrote: > The intent was to guarantee that the ORB called _add_ref() enough times > to make sure that the servant was not prematurely deleted. Any ORB > implementation strategy that guarantees that the ORB & POA hold the > reference count high enough to prevent premature servant destruction and > yet decrement it at the right time to allow for proper servant > destruction should be allowed. > > > The language is not precise enough, I think... > > English isn't precise enough. Anyone for Loglan? :-) How about better English? ;-) Would it be OK to say that _add_ref() is called *exactly* once *if* this call adds a new entry to the AOM? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jbiggar@corvette.floorboard.com Message-ID: <38C03DA2.A04E4361@floorboard.com> Date: Fri, 03 Mar 2000 14:33:06 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: C++ Revision Task Force Subject: Re: ref counting ambiguous? References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: &aU!!_,9!!1ljd9QZ#!! Michi Henning wrote: > > On Fri, 3 Mar 2000, Jonathan Biggar wrote: > > > The intent was to guarantee that the ORB called _add_ref() enough > times > > to make sure that the servant was not prematurely deleted. Any > ORB > > implementation strategy that guarantees that the ORB & POA hold > the > > reference count high enough to prevent premature servant > destruction and > > yet decrement it at the right time to allow for proper servant > > destruction should be allowed. > > > > > The language is not precise enough, I think... > > > > English isn't precise enough. Anyone for Loglan? :-) > > How about better English? ;-) > > Would it be OK to say that _add_ref() is called *exactly* once *if* > this > call adds a new entry to the AOM? Perhaps the best way to fix this is to change all of the "at least once" language to just "once" and add some supporting text somewhere that states that the ORB is allowed to call additional _add_ref()/_remove_ref() pairs internally as long as it still guarantees that "everything works right". :-) -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Sat, 4 Mar 2000 08:57:04 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: C++ Revision Task Force Subject: Re: ref counting ambiguous? In-Reply-To: <38C03DA2.A04E4361@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: (>8e9;K~!!*aI!!X44e9 On Fri, 3 Mar 2000, Jonathan Biggar wrote: > > Would it be OK to say that _add_ref() is called *exactly* once *if* this > > call adds a new entry to the AOM? > > Perhaps the best way to fix this is to change all of the "at least once" > language to just "once" and add some supporting text somewhere that > states that the ORB is allowed to call additional > _add_ref()/_remove_ref() pairs internally as long as it still guarantees > that "everything works right". :-) That would be OK with me too. The important thing is to make it clear that every time a servant is newly added to the AOM, one call to _add_ref() will be made, so etherealize() is expected to call _remove_ref() exactly once to get rid of the servant again. Out of curiosity (I know we can't change this), why was responsibility for calling _remove_ref() given to etherealize(). It would seem easier if the ORB had made that call once etherealize() returned. Or is there something subtle I am missing? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jbiggar@corvette.floorboard.com Message-ID: <38C044F9.796F8459@floorboard.com> Date: Fri, 03 Mar 2000 15:04:25 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: C++ Revision Task Force Subject: Re: ref counting ambiguous? References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 1c_d9(WDe9dl)e9MDbd9 Michi Henning wrote: > > On Fri, 3 Mar 2000, Jonathan Biggar wrote: > > > > Would it be OK to say that _add_ref() is called *exactly* once > *if* this > > > call adds a new entry to the AOM? > > > > Perhaps the best way to fix this is to change all of the "at least > once" > > language to just "once" and add some supporting text somewhere > that > > states that the ORB is allowed to call additional > > _add_ref()/_remove_ref() pairs internally as long as it still > guarantees > > that "everything works right". :-) > > That would be OK with me too. The important thing is to make it > clear > that every time a servant is newly added to the AOM, one call to > _add_ref() > will be made, so etherealize() is expected to call _remove_ref() > exactly > once to get rid of the servant again. > > Out of curiosity (I know we can't change this), why was > responsibility for > calling _remove_ref() given to etherealize(). It would seem easier > if the > ORB had made that call once etherealize() returned. Or is there > something > subtle I am missing? For backwards compatibility. For non-reference-counted servants, etherealize() needs to delete the servant. If the ORB tried to call _remove_ref() after etherealized returned, BOOM! -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Sat, 4 Mar 2000 09:06:09 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: C++ Revision Task Force Subject: Re: ref counting ambiguous? In-Reply-To: <38C044F9.796F8459@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: hYg!!$gW!!MJWd9'%E!! On Fri, 3 Mar 2000, Jonathan Biggar wrote: > > Out of curiosity (I know we can't change this), why was responsibility for > > calling _remove_ref() given to etherealize(). It would seem easier if the > > ORB had made that call once etherealize() returned. Or is there something > > subtle I am missing? > > For backwards compatibility. For non-reference-counted servants, > etherealize() needs to delete the servant. If the ORB tried to call > _remove_ref() after etherealized returned, BOOM! Ah, of course. Thanks! Michi. From: Paul Kyzivat To: C++ Revision Task Force Subject: RE: ref counting ambiguous? Date: Fri, 3 Mar 2000 21:19:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 73Td9,Xf!!\f:!!P^gd9 > Out of curiosity (I know we can't change this), why was > responsibility for > calling _remove_ref() given to etherealize(). It would seem > easier if the > ORB had made that call once etherealize() returned. Or is > there something subtle I am missing? You can't do the _remove_ref in the POA after the return from etherealize, because reference counting is optional and etherealize might have already deleted the servant. You can't do it before etherealize because then it might make the servant go away before etherealize can look at it. So there is no other choice. From: Paul Kyzivat To: cxx_revision@omg.org Subject: RE: Requiring ref counting in ServantBase Date: Thu, 6 Apr 2000 16:11:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: -Ved9d9@!!;c>!!)Vk!! Bill, This is an incompatible change, and will break existing server applications that are not expecting reference counting. I agree with you that ServantBase_var will only work for reference counted servants, but this is the only _var that is broken in this way. I think it is sufficient to add a disclaimer to the description of ServantBase_var. (No matter what is done, as long as reference counting can be overridden by the user, the ServantBase_var will only work conditionally.) Agreed that the specified calls to _remove_ref do nothing if reference counting is not implemented, but the point is that they are called in case it is implemented, so the calls are important. Paul > -----Original Message----- > From: Bill Beckwith [mailto:bill.beckwith@ois.com] > Sent: Thursday, April 06, 2000 12:47 PM > To: cxx_revision@omg.org > Cc: issues@omg.org > Subject: Requiring ref counting in ServantBase > > > [I'm sending this again because I never saw it come > back from the list server.] > > Problem: > > The current requirement that the default implementations of > _add_ref and _remove_ref in ServantBase do nothing creates > several problems: > > 1. The text in the C++ mapping that states that _remove_ref > must be called on a servant means nothing unless the ref > counting mix-in was used by the servant author. > > 2. The intended semantics of _var types as "smart pointers" > is upheld only if the servant author goes to the extra > step of using the ref counting mix-in. > > 3. In many places the C++ mapping explicitly or implicitly > states that _var types will recover memory for the application > developer: > > 1.3.1: > > Client code frequently will use the object reference > variable type (A_var) because a variable will > automatically release its object reference when it is > deallocated or when assigned a new object reference. > > 1.3.6: > > When a _var is passed as an out parameter, any > previous value it refers to must be implicitly > released. > > In addition, there are many places in the C++ mapping where > the specification of _var types for arrays, structs, strings, > sequences, type Any, type codes, value types, value boxes, > value factories, etc. guarantees that the memory will be > reclaimed when the _var goes out of scope. This makes it > easy for users to believe that all _var types will release > storage for the objects that point to. > > Benefits of Proposed Resolution: > > Users can depend on ORB's to manage servant memory by default > rather than by exception. > > Specification text that promises or implies automatic memory > reclamation need not change. > > Existing user code will still compile. > > Proposed Resolution: > > Replace the text in section 1.36.1 beginning with the sentence: > > Servant instances may implement reference counting to prevent > themselves from being destroyed while the application is > still using them. > > and section 1.36.2 in its entirety with: > > Servant instances may implement reference counting to prevent > themselves from being destroyed while the application is still > using them. Servant reference counting is performed using the > _add_ref and _remove_ref functions declared in ServantBase. The > default implementations of _add_ref and _remove_ref supplied by > ServantBase provide true reference counting. An instance of a > servant class derived from ServantBase initially has a reference > count of one. Invoking _add_ref on the servant instance > increases its reference count by one. Invoking _remove_ref on > the servant instance decreases its reference count by one; if the > resulting reference count equals zero, _remove_ref invokes delete > on its this pointer in order to destroy the servant. For ORBs > that operate in multi-threaded environments, the implementations > of _add_ref and _remove_ref that the ServantBase class provides > shall be thread-safe. > > ServantBase supports copy construction and the default assignment > operation. Copy construction always sets the reference count of > the new servant instance to one. The default assignment > implementation merely returns *this and does not affect the > reference count. > > For servants that require that servants are not reference > counted, these functions are virtual and thus may be overridden > by derived servant classes. A default mix-in class is also > provided to remove the reference counting in the PortableServer > namespace; please see Section 1.36.2, "Servant No Reference > Counting Mix-In," on page 1-??? for more details. Details > concerning POA and application responsibilities with respect to > reference counting can be found in Section 1.36.4, "Servant > Memory Management Considerations," on page 1-???. > > Note that for applications that depended on the the > RefCountServantBase provided in previous revisions of this > specification ORBs must provide a default implementation of this > mix-in class in the PortableServer namespace that essentially > does nothing: > > // C++ > namespace PortableServer > { > class RefCountServantBase : public virtual ServantBase > { > public: > ~RefCountServantBase(); > protected: > RefCountServantBase(const RefCountServantBase&); > RefCountServantBase& operator=(const RefCountServantBase&); > private: > // ...other implementation details... > }; > > } > > 1.36.2 Servant No Reference Counting Mix-In > > The PortableServer namespace also provides a standard servant > mix-in class to remove the reference counting: > > // C++ > namespace PortableServer > { > class NoRefCountServantBase : public virtual ServantBase > { > public: > ~NoRefCountServantBase(); > virtual void _add_ref() {} > virtual void _remove_ref() {} > protected: > NoRefCountServantBase() {} > NoRefCountServantBase(const NoRefCountServantBase&) {} > NoRefCountServantBase& operator=(const > NoRefCountServantBase&); > private: > // ...other implementation details... > }; > } > > The NoRefCountServantBase mix-in class overrides the inherited > _add_ref and _remove_ref functions it inherits from ServantBase, > in order to override and remove the default reference counting in > ServantBase. >