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

If you choose the default policy of single_threaded, there is no thread safety, but there is also no overhead in using a mutex and using a volatile pointer.
Volatile in C++ doesn't really help with threading... Check out <
http://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for...
for one of many articles on the subject. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
Thank you for the feedback. That article and the accompanying discussion
is very interesting and informative. However, given the design of 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 Also note, that the ThreadingModel for Singularity is policy based, so users of the class are free to develop alternative thread-safe policies, using whatever techniques are appropriate for their environment. Thank you, Ben Robinson, Ph.D.

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. 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. 2) 2011/6/25 Ben Robinson <icaretaker@gmail.com>:
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! Best regards, Antony Polukhin
participants (2)
-
Antony Polukhin
-
Ben Robinson