Question

I have an object (Client * client) which starts multiple threads to handle various tasks (such as processing incoming data). The threads are started like this:

// Start the thread that will process incoming messages and stuff them into the appropriate queues.
mReceiveMessageThread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)receiveRtpMessageFunction, this, 0, 0);

These threads all have references back to the initial object, like so:

  // Thread initialization function for receiving RTP messages from a newly connected client.
  static int WINAPI receiveRtpMessageFunction(LPVOID lpClient)
  {
     LOG_METHOD("receiveRtpMessageFunction");
     Client * client = (Client *)lpClient;
     while(client ->isConnected())
     {
        if(client ->receiveMessage() == ERROR)
        {
           Log::log("receiveRtpMessageFunction Failed to receive message");
        }
     }

     return SUCCESS;
  }

Periodically, the Client object gets deleted (for various good and sufficient reasons). But when that happens, the processing threads that still have references to the (now deleted) object throw exceptions of one sort or another when trying to access member functions on that object.

So I’m sure that there’s a standard way to handle this situation, but I haven’t been able to figure out a clean approach. I don’t want to just terminate the thread, as that doesn’t allow for cleaning up resources. I can’t set a property on the object, as it’s precisely properties on the object that become inaccessible.

Thoughts on the best way to handle this?

Answer 1

You don’t have much leeway because of the running threads.

No combination of shared_ptr + weak_ptr may save you… you may call a method on the object when it’s valid and then order its destruction (using only shared_ptr would).

The only thing I can imagine is to first terminate the various processes and then destroy the object. This way you ensure that each process terminate gracefully, cleaning up its own mess if necessary (and it might need the object to do that).

This means that you cannot delete the object out of hand, since you must first resynchronize with those who use it, and that you need some event handling for the synchronization part (since you basically want to tell the threads to stop, and not wait indefinitely for them).

I leave the synchronization part to you, there are many alternatives (events, flags, etc…) and we don’t have enough data.

You can deal with the actual cleanup from either the destructor itself or by overloading the various delete operations, whichever suits you.