Jeff Garland wrote:
Happy to hear you're still working on this :-)
Thanks :)
I have been designing a new singleton library from the ground up. I feel that this is necessary because the first version was not designed with the concerns of threading in mind, and such concerns cannot easily be addressed efficiently as an afterthought.
This sounds a bit drastic. I'm sorry I didn't have time to follow the review in detail, but I would imagine that much of the interface was perfectly fine.
The old version was perfectly usable, but by redesigning after everything I learned the first time I have been able to make significant organizational improvements, simplifications, and interface enhancements. I didn't start over just because of threading concerns.
Question: With the new design, I am adding a policy to control exactly what happens if creation is attempted while the singleton instance exists. The options thus far include throwing an exception, doing nothing, or destroying and recreating the singleton, depending on the policy used.
I can't imagine wanting a client wanting an exception if a 'race condition' with multiple threads leads to several clients needing the singleton. I also don't think destroy and recreate makes much sense -- that would invalidate the reference of the first client. Why not just simplify and return the already created singleton in all cases?
Create, destroy, and access to member functions through smart pointers are locked, so a destroy followed by a recreate should not invalidate the pointer in another thread (based on their location in my code, destroy and create would be completed as one atomic step). When used by the other thread, the pointer would automatically forward to whichever instance exists. It could be useful to destroy and recreate a singleton for any number of reasons, but for one example consider a graphics engine. If the full screen application is minimized and then expanded again all graphics card resources would need to be reacquired. This is could be most naturally handled by destroying and recreating a singleton in charge of the display.
Does it make sense to have a similar policy for what happens when attempting to destroy an already destroyed instance? I can think of a few options that would make sense, such as doing nothing, throwing an exception, asserting, or creating the instance so that it can be re-destroyed, but I do not know if these would actually be useful enough to justify a point of customization.
Seems doubtful to me.
I tend to agree. Although at first I thought that the destruction of an already destroyed instance was similar semantically to a double delete (and hence should throw an exception) I now no longer think that it makes sense to regard double destruction as a programming error, especially in multi-threaded contexts. Thanks for the comments, hopefully the first version of the new singleton library will be ready for release before this summer is out. -Jason