Re: [boost] Is there interest in an alternative to the Singleton anti-pattern?

Subject: Re: [boost] Is there interest in an alternative to the Singleton anti-pattern?
From: Ben Robinson (icaretaker_at_[hidden])
Date: 2011-06-27 02:17:22

>
> I would like to see the updated source code. Even if boost vault is
> deprecated and moved to github, it is still a good place to post
> files.
>

I have posted the files to:

http://www.mediafire.com/?d8kn5fx2n5d22

>
> Two more remarks:
> 1) it would be great to use auto_ptr for instance_ptr_type. It will
> make sure that the resource is deleted and the constructor called.
>

The purpose of auto_ptr is to clean up the instance automatically.  It was a
design goal to make destruction of the Singularity explicit, especially in
multi-threaded contexts.  However, users can create custom ThreadingModel
policies which use any kind of smart pointer they desires.  I thought to
provide the only a primitive pointer for the included policies.

> 2)
> 2011/6/25 Ben Robinson <icaretaker_at_[hidden]>:
> > Singularity, I feel I still must make "instance_ptr" volatile for thread
> > safety. ?If I do not, the compiler can store the pointer in a register,
> and
> > other threads of execution will not see changes to its value. ?The linked
> > article seems mostly concerned with fencing access to the variable, which
> I
> > am achieving by using a mutex object. ?I only need volatile to
> > prevent effectively reading a "cached" value for the pointer. ?I found
> the
> > following article by Andrei Alexandrescu especially interesting:
> > http://drdobbs.com/cpp/184403766
>
>  It is not thread safe. Consider the article
> http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf by Scott
> Meyers and Andrei Alexandrescu. In the article by Andrei Alexandrescu
> at http://drdobbs.com/cpp/184403766 there is no construction of object
> in LockingPtr, and that makes a big difference!
>

Singularity does not using the Double-Checked Locking Pattern.  When using
the multi_threaded policy, it always acquire the mutex before accessing the
volatile instance pointer.  Therefore, it is thread safe, although it is
certainly not as efficient as possible.

The recommended usage of Singularity is without a globally accessible get()
function, so the performance of create() and destroy() should not be an
issue.  If global_access is enabled, it would be advisable to minimize calls
to get(), such as calling get() once per thread, storing the result in
thread-local storage.

> Best regards,
> Antony Polukhin

I greatly appreciate the feedback you are providing.  In addition, the
linked article was a fascinating read.

Thank you,

Ben Robinson, Ph.D.