Thread-safe singleton pattern
I propose thread safe singleton pattern implementation (see http://www.research.ibm.com/designpatterns/pubs/ph-jun96.txt). I have attached "singleton.hpp" to this letter. Below is the test program: #include <stdio.h> #include <singleton.hpp> class A : public boost::Singleton<A> { // // Only Singleton class can create and delete us! // SINGLETON_IS_MY_FRIEND; public: void foo(){ printf("foo!\n"); } A(){ printf("A()\n"); } ~A(){ printf("~A()\n"); } }; void main() { // It is not compiled: //A a = A::Instance(); // That is exactly as it should be used: A::Instance().foo(); } Test program outputs: A() foo! ~A() My question: Does Boost community think that boost::Singleton is convenient (or successful) solution?
This suffers from the same problems as your last singleton. (Probably should have kept it in that discussion, by the way.). Also, instead of forcing people to have threaded or not, make it a policy. On Mon, Jan 25, 2010 at 3:49 PM, Andrew Chinkoff <achinkoff@gmail.com>wrote:
I propose thread safe singleton pattern implementation (see http://www.research.ibm.com/designpatterns/pubs/ph-jun96.txt).
I have attached "singleton.hpp" to this letter.
Below is the test program:
#include <stdio.h> #include <singleton.hpp>
class A : public boost::Singleton<A> { // // Only Singleton class can create and delete us! // SINGLETON_IS_MY_FRIEND; public: void foo(){ printf("foo!\n"); } A(){ printf("A()\n"); } ~A(){ printf("~A()\n"); } };
void main() { // It is not compiled: //A a = A::Instance(); // That is exactly as it should be used: A::Instance().foo(); }
Test program outputs: A() foo! ~A()
My question: Does Boost community think that boost::Singleton is convenient (or successful) solution?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- GMan, Nick Gorski
Your implementation seems to be a fairly standard implementation of double checked locking, and thus is likely vulnerable to the issues outlined in C++ and the Perils of Double-Checked Locking<http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf> . On Mon, Jan 25, 2010 at 7:44 PM, GMan <gmannickg@gmail.com> wrote:
This suffers from the same problems as your last singleton. (Probably should have kept it in that discussion, by the way.). Also, instead of forcing people to have threaded or not, make it a policy.
On Mon, Jan 25, 2010 at 3:49 PM, Andrew Chinkoff <achinkoff@gmail.com
wrote:
I propose thread safe singleton pattern implementation (see http://www.research.ibm.com/designpatterns/pubs/ph-jun96.txt).
I have attached "singleton.hpp" to this letter.
Below is the test program:
#include <stdio.h> #include <singleton.hpp>
class A : public boost::Singleton<A> { // // Only Singleton class can create and delete us! // SINGLETON_IS_MY_FRIEND; public: void foo(){ printf("foo!\n"); } A(){ printf("A()\n"); } ~A(){ printf("~A()\n"); } };
void main() { // It is not compiled: //A a = A::Instance(); // That is exactly as it should be used: A::Instance().foo(); }
Test program outputs: A() foo! ~A()
My question: Does Boost community think that boost::Singleton is convenient (or successful) solution?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- GMan, Nick Gorski _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Alex Miller wrote:
Your implementation seems to be a fairly standard implementation of double checked locking, and thus is likely vulnerable to the issues outlined in C++ and the Perils of Double-Checked Locking<http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf>
Making Singleton is a kind of Sisyphus labour. I'm wondering if Monostate would be a better candidate for such project. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On Mon, 25 Jan 2010, Alex Miller wrote:
Your implementation seems to be a fairly standard implementation of double checked locking, and thus is likely vulnerable to the issues outlined in C++ and the Perils of Double-Checked Locking<http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf> .
yes, the implementation is broken; see e.g. http://www.chaoticmind.net/~hcb/projects/boost.atomic/doc/atomic/usage_examp... for a correct one, using Boost.Atomic
Helge Bahmann wrote:
see e.g.
http://www.chaoticmind.net/~hcb/projects/boost.atomic/doc/atomic/usage_examp...
for a correct one, using Boost.Atomic
Is *delete* missing intentionally? Does boost::atomic::load() or oost::atomic::store() fall back to locking a mutex on any platform? BR, Dmitry
Regards, Helge! This is the fragment of $(BOOST_ROOT)/boost/memory_order.hpp: namespace boost { enum memory_order { memory_order_relaxed = 0, memory_order_acquire = 1, memory_order_release = 2, memory_order_acq_rel = 3, // acquire | release memory_order_seq_cst = 7 // acq_rel | 4 }; } // namespace boost My questions: 1) Where is the memory_order_consume constant? I failed to compile your "Double Check Singleton Pattern" sample, because it uses "memory_order_consume" constant. 2) How soon Boost.Atomic will be included into Boost release? Best, Andrew. -- View this message in context: http://old.nabble.com/Thread-safe-singleton-pattern-tp27315850p27344579.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Regards, Helge! This is the fragment of $(BOOST_ROOT)/boost/memory_order.hpp: namespace boost { enum memory_order { memory_order_relaxed = 0, memory_order_acquire = 1, memory_order_release = 2, memory_order_acq_rel = 3, // acquire | release memory_order_seq_cst = 7 // acq_rel | 4 }; } // namespace boost My questions: 1) Where is the memory_order_consume constant? I failed to compile your "Double Check Singleton Pattern" sample, because it uses "memory_order_consume" constant. 2) How soon Boost.Atomic will be included into Boost release? Best, Andrew. -- View this message in context: http://old.nabble.com/Thread-safe-singleton-pattern-tp27315850p27344594.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Hi Andrew, Am Wednesday 27 January 2010 19:35:10 schrieb Andrew Chinkoff:
Regards, Helge!
This is the fragment of $(BOOST_ROOT)/boost/memory_order.hpp: [...]
My questions:
1) Where is the memory_order_consume constant? I failed to compile your "Double Check Singleton Pattern" sample, because it uses "memory_order_consume" constant.
Released versions of boost do not include it yet, but it is defined in trunk: https://svn.boost.org/trac/boost/browser/trunk/boost/memory_order.hpp You either have to manually add the definition, or checkout trunk
2) How soon Boost.Atomic will be included into Boost release?
Obviously not in the pending release ;-) so I have slowed down a bit. I would however propose this for fast-path review for maybe the next release -- after all it merely formalizes an interface for atomic operations currently dispersed throughout the library. The real chore will however probably be replacing all other instances of atomic variable implementations. Best regards, Helge
I will checkout trunk. Thanks for response. I wish creative successes in your work! Andrew. -- View this message in context: http://old.nabble.com/Thread-safe-singleton-pattern-tp27315850p27346662.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Alex Miller wrote:
Your implementation seems to be a fairly standard implementation of double checked locking, and thus is likely vulnerable to the issues outlined in C++ and the Perils of Double-Checked Locking<http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf> .
On Mon, Jan 25, 2010 at 7:44 PM, GMan <gmannickg@gmail.com> wrote:
This suffers from the same problems as your last singleton. (Probably should have kept it in that discussion, by the way.). Also, instead of forcing people to have threaded or not, make it a policy.
On Mon, Jan 25, 2010 at 3:49 PM, Andrew Chinkoff <achinkoff@gmail.com
wrote:
Please don't top post. Refer to http://www.boost.org/community/policy.html#quoting for more information. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
I thought I was familiar with the guidelines and never remembered this. I top-post all the time. It seems much more natural to me when it's not convenient to intersperse comments into the previous message. Why I like top posting: a) It means that I don't have to scroll to the bottom of a message which is sometimes pretty long. b) To me it is more natural to follow the style of other communications (artilcle, books, etc) which make their point in the main text and refer to footnotes, bibliographies, etc at the end of the main text. The link says no top-posting - but there is no rational for this. What is it and why is it bad? Robert Ramey Stewart, Robert wrote:
Please don't top post. Refer to http://www.boost.org/community/policy.html#quoting for more information.
_____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of vi ruses. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
I thought I was familiar with the guidelines and never remembered this.
It has been mentioned on the list repeatedly over the years.
I top-post all the time. It seems much more natural to me when it's not convenient to intersperse comments into the previous message. Why I like top posting:
a) It means that I don't have to scroll to the bottom of a message which is sometimes pretty long.
If the quoted message is pretty long, then you've violated the "don't overquote" part of the policy.
b) To me it is more natural to follow the style of other communications (artilcle, books, etc) which make their point in the main text and refer to footnotes, bibliographies, etc at the end of the main text.
That's nice, but it isn't the accepted style and there are at least as many that like to know what you're responding to when they read your post.
The link says no top-posting - but there is no rational for this. What is it and why is it bad?
The Discussion Policy page includes a link to the following page which does provide rationale: http://www.netmeister.org/news/learn2quote.html. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
The link says no top-posting - but there is no rational for this. What is it and why is it bad?
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Philippe
Because you lose context. Case in point. On Wed, Jan 27, 2010 at 2:09 AM, Robert Ramey <ramey@rrsd.com> wrote:
I thought I was familiar with the guidelines and never remembered this.
I top-post all the time. It seems much more natural to me when it's not convenient to intersperse comments into the previous message. Why I like top posting:
a) It means that I don't have to scroll to the bottom of a message which is sometimes pretty long. b) To me it is more natural to follow the style of other communications (artilcle, books, etc) which make their point in the main text and refer to footnotes, bibliographies, etc at the end of the main text.
The link says no top-posting - but there is no rational for this. What is it and why is it bad?
Robert Ramey
Stewart, Robert wrote:
Please don't top post. Refer to http://www.boost.org/community/policy.html#quoting for more information.
_____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of vi ruses. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
On Tue, Jan 26, 2010 at 11:14 AM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
Because you lose context. Case in point.
And here is an awesome example by Joel:
A: Yes.
Q: Are you sure?
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email?
If you are not convinced that it is wrong by the simple example above, now try to mix top and bottom posting:
A: Yes.
Q: Are you sure?
Q: Why is top posting annoying in email? A: Because it reverses the logical flow of conversation.
I don't know about you, but that's simply crazy!
The correct way:
Q: Why is top posting annoying in email? A: Because it reverses the logical flow of conversation. Q: Are you sure? A: Yes.
At Tue, 26 Jan 2010 10:09:43 -0800, Robert Ramey wrote:
I thought I was familiar with the guidelines and never remembered this.
I top-post all the time. It seems much more natural to me when it's not convenient to intersperse comments into the previous message. Why I like top posting:
a) It means that I don't have to scroll to the bottom of a message which is sometimes pretty long. b) To me it is more natural to follow the style of other communications (artilcle, books, etc) which make their point in the main text and refer to footnotes, bibliographies, etc at the end of the main text.
c) You don't confuse or even *upset* (as I've discovered the hard way) many people in the business world, where top-posting and overquoting is the accepted standard. Every message drags along the entire thread history with it, and you keep a record of everything by storing the final message. (yuck) It's a cultural thing, and Boost fits into the open-source programmer weenie culture much more than the business culture. when-in-rome-ly y'rs, Dave -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
On 22.03.2010 23:25, David Abrahams wrote:
At Tue, 26 Jan 2010 10:09:43 -0800, Robert Ramey wrote:
I thought I was familiar with the guidelines and never remembered this.
I top-post all the time. It seems much more natural to me when it's not convenient to intersperse comments into the previous message. Why I like top posting:
a) It means that I don't have to scroll to the bottom of a message which is sometimes pretty long. b) To me it is more natural to follow the style of other communications (artilcle, books, etc) which make their point in the main text and refer to footnotes, bibliographies, etc at the end of the main text.
c) You don't confuse or even *upset* (as I've discovered the hard way) many people in the business world, where top-posting and overquoting is the accepted standard. Every message drags along the entire thread history with it, and you keep a record of everything by storing the final message. (yuck) It's a cultural thing, and Boost fits into the open-source programmer weenie culture much more than the business culture.
Personally, I _hate_ top-posting, because it doesn't allow me to answer the particular points in the opponent's message. Or put it another way, it requires me to reformat the whole message in order to keep it readable afterwards.
Personally, I _hate_ top-posting, because it doesn't allow me to answer the particular points in the opponent's message. Or put it another way, it requires me to reformat the whole message in order to keep it readable afterwards. Hi, I believe there is nothing wrong with top posting, as well it's nothing wrong with bottom. What is really annoying is when there is both top and bottom postings on the same thread. This makes it difficult to read. For this motive, most mailing lists adopt one or other. []'s -- Felipe de Oliveira Tanus E-mail: fotanus@gmail.com Blog: http://www.itlife.com.br Site: http://www.inf.ufrgs.br/~fotanus/ ----- "All we have to decide is what to do with the time that is given us." - Gandalf
Andrey Semashev wrote:
On 22.03.2010 23:25, David Abrahams wrote:
At Tue, 26 Jan 2010 10:09:43 -0800, Robert Ramey wrote:
Personally, I _hate_ top-posting, because it doesn't allow me to answer the particular points in the opponent's message. Or put it another way, it requires me to reformat the whole message in order to keep it readable afterwards.
Truth is it's not a huge deal for me. In this case I'll just go with the flow and reserver my energy for bigger battles to come. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Andrew Chinkoff wrote:
I propose thread safe singleton pattern implementation (see http://www.research.ibm.com/designpatterns/pubs/ph-jun96.txt).
Just use static variables at function scope and there you go, you have a thread-safe implementation (in C++0x).
participants (15)
-
Alex Miller -
Andrew Chinkoff -
Andrey Semashev -
David Abrahams -
Dean Michael Berris -
Dmitry Goncharov -
Felipe Tanus -
GMan -
Helge Bahmann -
Mateusz Loskot -
Mathias Gaunard -
OvermindDL1 -
Philippe Vaucher -
Robert Ramey -
Stewart, Robert