Reference count problem in singleton container
On Wed, 13 Nov 2002 16:18:48 -0500, "Igor Tandetnik"
Quote:
>Do you have back pointers from children to master object? Do they
>maintain strong references?
Yes, I maintain back (parent) pointers, but they are weak
(non-reference counted) pointers.
I dug into the source code a little. Using
DECLARE_CLASSFACTORY_SINGLETON (as I do), means the created singleton
object is a CComObjectGlobal. AddRef and Release for that class simply
do _Module.Lock() and _Module.Unlock() -- see ATLCOM.H. Also, KB
article Q201321 mentions that ATL Singletons have a lifetime "tied to
the class factory; the singleton gets destroyed only when the class
factory is destroyed, which is when the DLL unloads".
So although I don't understand why they did it this way, at least I
understand the reference counts I am seeing.
Chris
Quote:
>> I have an in-proc ATL project that consists of a large number of
>> objects and containers of objects. There is one master object, which
>> is a singleton. All the other objects are children (or grandchildren,
>> etc.) of this master object.
>> Everything works fine (and we've been using it for a year or two now).
>> Recently in debugging another reference counting problem, I looked at
>> the reference count for the master object. I expected it to be 3 or 5
>> or something like that, but it was more than 20,000!
>> Putting in some trace statements and stepping into the startup code
>> with the de{*filter*}, I find that every time I create an object in my
>> hierarchy, the reference count of the master object increases by one.
>> I can be far down in the hierarchy, and still it increments the master
>> object reference count. I create objects by calling
>> CMyObject::_CreatorClass::CreateInstance, and I can check the
>> reference count before and after this call, and it goes up by one.
>> I looked at the module lock count, and that has the same value as the
>> singleton's reference count. Hmm, might be a clue. :)
>> FinalRelease of my master object =is= getting called. At first I
>> thought this meant someone must also be releasing those extra
>> refcounts, since almost all of the created objects are still in
>> existance at the beginninf of the master object's FinalRelease.
>> (Because the master object "owns" them, and releases them in
>> FinalRelease). But looking at the call stack, it appears that the
>> master object FinalRelease is being called long after my application
>> has terminated. The application is MFC, and there's none of the MFC
>> framework on the call stack. My FinalRelease is being called by
>> DllMain, and then ATL::CComModule::Term, etc. So perhaps FinalRelease
>> on this object is called whenever the DLL unloads, no matter what the
>> reference count situation is.
>> So, can anyone shed any light on how reference counts for ATL
>> singletons work?
>> TIA,
>> Chris
