Thread: smart pointer release

Originally Posted by Elysia

If two threads use the same variable then yes.

No it is not a problem!

The fundamentals of COM require that incrementing and decrementing the reference count be threadsafe, assuming you've correctly uses CComMultiThreadModel like you're supposed to if your COM object can live in a multi-threaded apartment. In this case it then uses InterlockedDecrement, so only one thread can ever see the refcount be decremented to zero. Furthurmore it would be a bug if the refcount were ever one and multiple threads called Release, though that still would not cause more than one thread to try and delete the object.
Thus only one of the threads can ever call delete on the object.

As I said, I use COM every day at work, and I don't think Elysia has used COM much, if at all.
You can certainly trust Elysia for a quick answer, but often not for a correct one.

Originally Posted by iMalc

No it is not a problem!

Of course it's a problem. It all depends on the implementation of the smart pointer class. Mayhap COM itself may be thread safe, but no the class itself.

As I said, I use COM every day at work, and I don't think Elysia has used COM much, if at all.
You can certainly trust Elysia for a quick answer, but often not for a correct one.

No always correct, no, but no one can be.
I have used COM somewhat, but never really implemented it nor used it in a threaded environment, so that is beyond me.
I don't know the depths of COM, either. I know how to use it, AddRef, Release, QueryInterface, CoCreateInstance, etc. And frankly, COM annoys me, so I avoid it. My knowledge on COM itself isn't perhaps what it should be.

Originally Posted by Elysia

Of course it's a problem. It all depends on the implementation of the smart pointer class. Mayhap COM itself may be thread safe, but no the class itself.

In th COM case, the functions that deal with the Refcounting are part of the class itself (intrusive), not part of the smart pointer class. Whether you use CComPtr<IUnknown> or IUnknownPtr, or some other home made smart pointer, they all have to go through to calls to Release on the IUnknown interface itself.
You're probably thinking of boost's shared_ptr with its non-intrusive refcounting.

Now that in itself doesn't automatically mean that a home grown start pointer class is instantly perfect, for example it is easy to get the assignment operator wrong. But it does still mean that the destructor will only ever get called once, purely because it is COM that is responsible for this and not the smart pointer itself, which is only responsible for calling AddRef and Release at the right time etc.
People should have no need to use homegrown smartpointers with COM anyway.

Intrusive refcounting would be the objects that your smart pointer class is meant to hold actually each contain the variable that holds their own reference count. This is often done by deriving from a base class that contains the reference count member. The smart pointer class then only needs to hold a pointer to the item, and can manipulate the reference count through that.

Non-intrusive would be where a seperate pointer to the reference count (which is allocated by the smart pointer class) is stored in the smart pointers that point to the same. This means the smart pointer has two pointer members, on of which is to memory allocated by it. But the class it is meant to hold doesn't have anything besides its own data, and doesn't ever know that it is being held in a smart pointer, or that its days are numbered by some refcount out there.

Yes, exactly.