Re: [boost] singleton_ptr

From: Jason Hise (chaos_at_[hidden])
Date: 2005-07-17 17:01:38

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