Smart Pointers and Multithreading

I've implemented smart pointer classes before for multithreaded environments. The only change you need to make for multithreading to the basic smart pointer idiom is wrap each increment and decrement/check with some sort of synchronization primitive. A good candidate on Win32 for these operations are InterlockedIncrement/InterlockedDecrement. (On non-Win32 platforms, you could use a semaphore for the ref count, or wrap your increments/decrements with a mutex.)

So your base reference-counted object would look something like this: (I've simplified it for brevity)

class CRefObject
{ public: void AddRef() { InterlockedIncrement(&m_refCount); }
          void Release() { if(InterlockedDecrement(&m_refCount) == 0) { DeleteThisObject(); }
  private: long m_refCount;
};

Then, assuming your existing smart pointer class already called the AddRef()/Release() routines, you really don't need any changes to your smart pointers unless you share them between threads. In that case, you must wrap the smart pointers copy constructors/assignment operators/anything that can change what the smart pointer points to with some sort of syncronization (a critical section in Win32 would do nicely).


Now I have to convince you why this is thread safe. The Interlocked* routines prevent this situation:

Object meef has a ref count of 2 because each thread has a smart pointer which references it. Both threads are simultaneously trying to create another reference to the object by copying their respective smart pointers into new smart pointers. Here is a time line of their actions through the copy constructors of the smart pointers (time goes down):

    Thread 1               Thread 2
    fetches ref count (temp= 2)
    increments it (temp++)        
    (task switch)
                           fetches ref count (temp = 2)
                           increments it (temp++)
                           stores ref count (meef.refCt = 3 now)
                           (task switch)
    stores ref count (meef.refCt = 3 now)

Note that the ref count should be 4, but its 3 because of inopportune task switching. The Interlocked* routines make the increments and decrements/checking atomic, so this can't happen.

Now, when I first started thinking about these issues I was convinced that there could be a case where one thread would decrement the ref count to zero, while at the same time another thread wants to increment the ref count by one, so the object gets deleted when it shouldn't. But further analysis shows that this should never happen - because the second thread should NOT have a smart pointer to the object in the first place, and thus can't increment its ref count at all (because remember, at the beginning of this whole situation, the ref count of the object would have to be at 1. Which means the first thread's smart pointer is the only reference to that object, and once that reference is released, the object should rightly be deleted).

Another interesting issue is when you have a smart pointer that is shared between multiple threads, i.e. you have a shared data area that contains a smart pointer. But I've decieded that this presents no problem - as long as the smart pointer is only created once and deleted once, it should be fine. The key is to remember is the reference is held with the smart pointer, not with the thread itself.

I also was able to get the syntax of using the smart pointer to be consistent with normal pointer syntax for every case except for casting to a derived class. Let me illustrate:

Normal method:  pMeef = (CMeef *) pFoo; // pFoo is a pointer to a base type of pMeef
Smart Pointer method pMeef = (CMeef *) (CFoo *) pFoo; // pFoo is a smart pointer to a base type of pMeef

I don't have the code handy but I could post it later if you want.