AddRef and Release

Hello everyone,


Here is section of code I wrote about AddRef and Release. My questions are,

1. Are they correct code?
2. It looks redundant to call so many times of AddRef and Release just to make the counter consistent, if you were me, do you have ways to write better code?

Code:

---

IX* pI = NULL;
pI = pI1;
pI -> AddRef();

...

pI -> Release(); // release before binding to a new interface
pI = pI2;
pI -> AddRef();

...

pI -> Release(); // release before binding to a new interface
pI = pI3;
pI -> AddRef();

...

---

thanks in advance,
George

AddRef() adds one to the reference count and Release() decrements it by one.
When the reference count reaches 0, the object is destroyed. So you shouldn't call Release() before reassigning. Call it after.
Even better it to wrap the COM object in a RAII class where the constructor calls AddRef and the destructor calls Release().

Thanks Elysia,


I do not agree with "So you shouldn't call Release() before reassigning". I think you mean write code like this,

Code:

---

pI = pI2;
pI -> Release();
pI -> AddRef();

---

other than like

Code:

---

pI -> Release(); // release before binding to a new interface
pI = pI2;
pI -> AddRef();

---

Ths problem of your comment is pI1 may pointed to another component, and we need to call "its (the component pointed by pI1)" Release, other than pI2's Release.

Please feel free to correct me if I am wrong.

Quote:

---

Originally Posted by Elysia

AddRef() adds one to the reference count and Release() decrements it by one.
When the reference count reaches 0, the object is destroyed. So you shouldn't call Release() before reassigning. Call it after.
Even better it to wrap the COM object in a RAII class where the constructor calls AddRef and the destructor calls Release().

---

regards,
George

Quote:

---

Originally Posted by George2

Thanks Elysia,

I do not agree with "So you shouldn't call Release() before reassigning". I think you mean write code like this,

other than like

Ths problem of your comment is pI1 may pointed to another component, and we need to call "its (the component pointed by pI1)" Release, other than pI2's Release.

Please feel free to correct me if I am wrong.

regards,
George

---

But if you create a COM object -> ref count = 1.
You call Release before reassigning and calling AddRef -> ref count = 1 - 1 = 0. Boom! Object destroyed!

Thanks Elysia,


The object will not be destroyed if any other interface holds the reference to it, like pI1. But your implementation also has issue as I pointed in post #3. Any comments?

Quote:

---

Originally Posted by Elysia

But if you create a COM object -> ref count = 1.
You call Release before reassigning and calling AddRef -> ref count = 1 - 1 = 0. Boom! Object destroyed!

---

regards,
George

How does the object know that something holds a reference to it?
Everytime you create an object, its reference count is increased. So when you no longer need the interface, you decrement it through Release and get rid of the pointer. That way the object is destroyed.
You're destroying it prematurely.

For all intents and purposes, if you make another pointer to the object, call AddRef first, then call Release on the old pointer and get rid of it.

Sorry Elysia, I do not agree with you. :-)


1. "You're destroying it prematurely." Do you mean destroyed at statement "pI -> Release()"?

No. Please look at my original code. Suppose pI1 holds reference to the object instance, and even if we invoked pI -> AddRef(), then I -> Release(), pI1 still holds the reference to the object instance, so it is not destroyed at the statement pI -> Release().

Code:

---

IX* pI = NULL;
pI = pI1;
pI -> AddRef();

...

pI -> Release(); // release before binding to a new interface
pI = pI2;
pI -> AddRef();

...

pI -> Release(); // release before binding to a new interface
pI = pI3;
pI -> AddRef();

...

---

2. "call Release on the old pointer and get rid of it"

No. If we still need the old pointer, we should not call Release on it. Suppose we have an overlapped life time of interface? Agree?

If I am wrong with either (1) or (2), plesae feel free to correct me. :-)

Quote:

---

Originally Posted by Elysia

How does the object know that something holds a reference to it?
Everytime you create an object, its reference count is increased. So when you no longer need the interface, you decrement it through Release and get rid of the pointer. That way the object is destroyed.
You're destroying it prematurely.

For all intents and purposes, if you make another pointer to the object, call AddRef first, then call Release on the old pointer and get rid of it.

---

regards,
George

Quote:

---

Originally Posted by George2

1. "You're destroying it prematurely." Do you mean destroyed at statement "pI -> Release()"?

No. Please look at my original code. Suppose pI1 holds reference to the object instance, and even if we invoked pI -> AddRef(), then I -> Release(), pI1 still holds the reference to the object instance, so it is not destroyed at the statement pI -> Release().

---

How does the object know you hold a reference to it? It doesn't! It can't. It doesn't work that way. If there was a way to tell whenever a pointer held a reference to an object, there would be no need for reference counting, would there?

Quote:

---

2. "call Release on the old pointer and get rid of it"

No. If we still need the old pointer, we should not call Release on it. Suppose we have an overlapped life time of interface? Agree?

---

Absolutely. Only call Release() if you don't need the pointer anymore.

You shouldn't really ever need to call AddRef or Release directly. Just use a CComPtr<T> to hold the pointer to an interface of type T, instead.

I just fixed a nasty refcount bug a few hours ago in fact. Don't let this kind of bug occur in the first place.

Hi Elysia,

Quote:

---

Originally Posted by Elysia

How does the object know you hold a reference to it? It doesn't! It can't. It doesn't work that way. If there was a way to tell whenever a pointer held a reference to an object, there would be no need for reference counting, would there?

---

Sure, it could. It is what AddRef and Release in COM doing. In the implementation of AddRef, for example, we may invoke InterLockedIncrement to increase the counter member of the class instance to maintain the reference count. So, in this way, the object instance could know how much references are binded to it.

Have I understood your point correct? Please feel free to correct me if I am wrong.

Thanks for your advice, iMalc!


Do you have any comments to my code, do you think it is correct from function point of view even if it looks redundant?

Quote:

---

Originally Posted by iMalc

You shouldn't really ever need to call AddRef or Release directly. Just use a CComPtr<T> to hold the pointer to an interface of type T, instead.

I just fixed a nasty refcount bug a few hours ago in fact. Don't let this kind of bug occur in the first place.

---

regards,
George

Quote:

---

Originally Posted by George2

Sure, it could. It is what AddRef and Release in COM doing. In the implementation of AddRef, for example, we may invoke InterLockedIncrement to increase the counter member of the class instance to maintain the reference count. So, in this way, the object instance could know how much references are binded to it.

---

No. Note that knowing how many pointers are bound to an instance and reference counting aren't the same thing.
You are responsible for maintaining the correct reference count so that the number of pointers pointing to the same object is the same as the reference count. You can have one pointer to the object, yet the reference count can be 10. If you toss away that pointer, you have a memory leak because the reference count will still be 9 if you called Release.
Similarly, you can have a thousand pointers pointing to the object yet the reference count is only 1. So if you call Release, all those pointers will be invalid because reference count reaches 0 and the object is destroyed.

You must understand that it is the reference count that controls whether an object lives or dies. And just creating another pointer to the same object does not magically increase the reference count.

Thanks Elysia,


I have understood your point. Seems you have a different definition of reference count and pointer count. According to COM reference count practices, mentioned in the book Inside COM, if you assign the value to one pointer to interface, you need to call AddRef.

Looks like in COM world, they maintain pointer count as reference count, right? Looks like the pure reference count is not easy to maintain, suppose you have mixed use of local and global variables.

Quote:

---

Originally Posted by Elysia

No. Note that knowing how many pointers are bound to an instance and reference counting aren't the same thing.
You are responsible for maintaining the correct reference count so that the number of pointers pointing to the same object is the same as the reference count. You can have one pointer to the object, yet the reference count can be 10. If you toss away that pointer, you have a memory leak because the reference count will still be 9 if you called Release.
Similarly, you can have a thousand pointers pointing to the object yet the reference count is only 1. So if you call Release, all those pointers will be invalid because reference count reaches 0 and the object is destroyed.

You must understand that it is the reference count that controls whether an object lives or dies. And just creating another pointer to the same object does not magically increase the reference count.

---

regards,
George

Sorry, Elysia, in this case you're just totally wrong.

George2 is right.

iMalc is more right.

Thanks CornedBee,

Quote:

---

Originally Posted by CornedBee

Sorry, Elysia, in this case you're just totally wrong.

George2 is right.

iMalc is more right.

---

My question is answered.


regards,
George

Quote:

---

Originally Posted by CornedBee

Sorry, Elysia, in this case you're just totally wrong.

---

Well then, could you actually elaborate a bit?
Does objects exist while there is a pointer to them or do they go away when the reference count is 0?

They go away when the reference count is 0. That's the COM protocol.

I just read the thread carefully and I'm still fuzzy what you were arguing. But it didn't have anything to do with George2's code.

George2 were claiming that while a pointer is still pointing (read: has a reference) to the object, it won't go away.
I was explaining the concept that you can have a thousand pointers pointing to the object, and the ref count can still be 1, and if it was, if you called Release then, the object would be destroyed regardless how many pointers were pointing to the object because the reference count would reach 0.

Hi Elysia,


I am reading the book Inside COM. It mentioned when there is a new pointer, we should call AddRef, except that we optimize the performance and clear the nested relationship of pointers.

Looks like your concept of reference count and pointer count are different. But in COM (at least in the book), reference count and pointer count are both the same. :-)

Quote:

---

Originally Posted by Elysia

George2 were claiming that while a pointer is still pointing (read: has a reference) to the object, it won't go away.
I was explaining the concept that you can have a thousand pointers pointing to the object, and the ref count can still be 1, and if it was, if you called Release then, the object would be destroyed regardless how many pointers were pointing to the object because the reference count would reach 0.

---

regards,
George

Quote:

---

George2 were claiming that while a pointer is still pointing (read: has a reference) to the object, it won't go away.

---

No, he wasn't. He got confused by your insistence that Release() should be called after assigning a new value to the pointer (and just how would you call Release() on the old one then?) and merged the idea of having a pointer to the interface and having called AddRef() on it (thus keeping the object alive even if all other holders call Release() to match their own AddRef()). He was, in other words, thinking as a COM programmer should.

Anyway, the idea that when the reference count reaches 0, the object is destroyed is correct. And further, you shouldn't call either AddRef or Release; you should use CComPtr instead.
No trouble with pesky reference count then.

Thanks CornedBee,


This is what I am thinking. :-)

Quote:

---

Originally Posted by CornedBee

No, he wasn't. He got confused by your insistence that Release() should be called after assigning a new value to the pointer (and just how would you call Release() on the old one then?) and merged the idea of having a pointer to the interface and having called AddRef() on it (thus keeping the object alive even if all other holders call Release() to match their own AddRef()). He was, in other words, thinking as a COM programmer should.

---

regards,
George