   Synchronisation issue in multi-threaded app - reference count as solution?
  I'm trying to shoehorn referencing counting into one particular class in an existing project. This class is already used in many, many places in the code so changing it won't be easy.I think I need reference counting to overcome a synchronisation issue. The app is multithreaded and a particular pointer is being deleted in the main thread while another thread is trying to use it.This particular class is passed as a parameter in LOTS of places so I can't just wrap an instance in a smart pointer and pass the smart pointer instead. So any suggestions?Thanks   
  You'll need to implement a reference counting scheme which uses atomic CPU operators to be thread safe. There are a few impl, see this for example :http://www.ddj.com/architect/184401888Good Luck!-ddn;  What is the typical lifecycle of objects of this class? That is, when are they created, when are they used, and when are they destroyed? Who typically owns an instance of the problem class?Having some more details on the system would be very helpful; depending on what you're doing, there may be better solutions than reference counters.   ;  The lifetime is potentially hours if not days; it's a client connection object. The main thread creates and deletes instances and they are used whenever events occur on that client's socket; reads/disconnection/connection etc.However, my testing involves stopping the client immediately after it starts while data is being transmitted. So the message dispatcher thread grabs the connection pointer from the STL map. Before it can send the data, the client disconnects and the main thread deletes the object from the STL map. Then the dispatcher tries to use the pointer and *crash*.Sorry for the late reply - didn't have time to post again.Thanks   ;  I would simply wrap access to the map with a mutex; any time you look at the socket list to do some work with it, lock the mutex, and then release it once your operation is finished. That will prevent the main thread from nuking the pointer out from under the other thread.   ;  I hate it when people just reply "why don't you use boost", but... why don't you just use boost?Seriously, shared_ptr is reference counted and is thread-safe (whether you actually use boost or the very same class that's in C++09). Implementing reference counting yourself in a thread-safe manner is non-trivial and can turn out to be more painful than you anticipated. Storing shared_ptrs might save you all that.   ;  minor nitpick:Quote:Original post by samothC++09 C++0x;Quote:Original post by ApochPiQI would simply wrap access to the map with a mutex; any time you look at the socket list to do some work with it, lock the mutex, and then release it once your operation is finished. That will prevent the main thread from nuking the pointer out from under the other thread.That was my original plan, but the dispatcher might take > 1s to release the mutex and I don't want the main thread to block for that length of time.   ;Quote:Original post by phresnelminor nitpick:Quote:Original post by samothC++09 C++0xWell, if it's going to be 0x, then '09 darn well is the last remaining possibility anyway. :P;Quote:Original post by Red AntQuote:Original post by phresnelminor nitpick:Quote:Original post by samothC++09 C++0xWell, if it's going to be 0x, then '09 darn well is the last remaining possibility anyway. :PWhat about C++0A? [grin]   