Matthieu Fertré a écrit : > Kurosu a écrit : > >> Kurosu a écrit : >> >> >>> As the ml tends to strip even patches, you can find a mirror of the >>> patch here: >>> http://kurosu.free.fr/wormux/singleton.diff >>> > In my mind, you can apply it, it's far better that what we have > currently. (Anyway, I am thinking about atomicity with threads and how > it can be handle)... >
I'm back to point the different potential race conditions that can appear with the proposed implementation (current implementation is also sensible to race conditions). Here are some typical race conditions: 1) thread1 and thread2 ask for Object::GetInstance(), at the time of the requests, "singleton" is NULL. The 2 threads will start to create an instance, and one will be lost... 2) thread1 ask for Object::GetInstance() and thread2 ask for OtherObject::GetInstance(). If the two objects are null, singletons.push_back(this) may be called simultaneously and we have lost an object (C++ STL is not thread-safe). 3) thread1 tries to access to the singleton instance of Object and "singleton" is currently not NULL. BUT, thread 2 maybe deleting singleton itself, the problem is that singleton is set to NULL in the Singleton destructor. It means that thread1 can access to an object that is in destruction... Maybe there are some others! Sure, such race conditions will not arrive every days but we have already faced to the first one, so we have to take care. Regards, Matt (gentildemon) _______________________________________________ Wormux-dev mailing list Wormux-dev@gna.org https://mail.gna.org/listinfo/wormux-dev
