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.
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
2) 2011/6/25 Ben Robinson <icaretaker@gmail.com>: 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.