Hi Tanguy, I'm afraid I disagree with you on your assessment of the value of Singletons. Yes you have to implement them correctly, but that goes with any solution for managing resources, throwing out use of Singletons doesn't not solve problems, it just introduces new ones.
Robert. On Thu, Feb 12, 2009 at 12:00 PM, Tanguy Fautre <[email protected]> wrote: > Hi, > > I know this is a bit OT, but talking about OSG design... What about dropping > the singleton pattern entirely? > The more I use it or the more I encounter it, the more I think the singleton > pattern is completely broken. I know this is quite a bold claim, but bare > with me and let me explain. > > > - The life time of the singleton is not well defined in most cases, leading > to typical problems in C++ such as the initialization order problem. > > - The singleton pattern is an ambiguous design. It states that there is one > instance, but it does not state "per what". Is it per thread? Is it per > process? Is it per library/DLL? Is it per application? Is it per OS? Is it > per computer? > > > These two reasons alone make the typical singleton pattern broken in a lot of > cases. Most of the time without the programmer realizing it (myself > included). Anyone having to deal with singletons, static libraries and DLLs > knows how dangerous it becomes (e.g. you can often have several unwanted > instance of the singleton: one per DLL/EXE). Add thread-safety into the mix, > and it all becomes a nightmare. > > We've had already several problems with OSG in our project due to that, and > had to resort to ugly work arounds (e.g. manually calling undocumented OSG > release functions). > > > May I suggest that a better design is investigated for OSG 3.0? > > For example: > > class Initializer : private noncopyable > { > public: > > Initializer() > { > if (m_ref++ == 0) > initializeGlobalInstances(); > } > > ~Initializer() > { > if (--m_ref == 0) > uninitializeGlobalInstances(); > } > > private: > > initializeGlobalInstances(); > uninitializeGlobalInstances(); > > atomic_counter m_ref; > }; > > > Such as solution clearly defines the lifetime of the OSG library. It also > puts the responsibility of managing the lifetime of the library in the user > hands, who's more apt to know what is right for his application. It's also > exception-safe. > > Note that that implementing > initializeGlobalInstances/uninitializeGlobalInstances as thread-safe needs > careful thinking (see > http://www.justsoftwaresolutions.co.uk/articles/implementing_mutexes.html > especially the part about initialization and uninitialization). > > Also note that the Initializer has to be implemented in a DLL (i.e. shared > library) and not a static library, as it does not solve the multiple > singleton instances per process problem. However, I'm currently not aware of > any robust ways of solving that problem. > > > I hope I don't come as too arrogant on this. But I really think this part of > OSG doesn't do justice to the rest of the library. > > Cheers, > > Tanguy > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Jean-Sébastien Guay > Sent: Wednesday 11 February 2009 16:21 > To: OpenSceneGraph Users > Subject: Spam: Re: [osg-users] memory leak false positives on Windows > > Hi Cory, > >> I don't think anybody has questioned the design of OSG. > > Yes, Neil has said that perhaps we should consider "restructuring" to > avoid the false positives. This comes down to changing the design. > >> I also agree with you that making code concessions to accommodate tools >> is unfortunate, but it happens all the time. > > Yes, the coding changes to accomodate tools. But the design will stay > the same. It's the implementation that changes. That's what I was > talking about. > >> On the other hand, I'd like to know if code that explicitly unloads >> OSG would ever be accepted into the repository. I'm getting the sense >> that it would be if it were sufficiently transparent, simple and >> inexpensive. > > Yes, Robert said in this thread that he would accept something that > unloads/unrefs all singletons / static objects, but it might be hard to > get to all singletons since some exist in the implementation files only. > >>> (btw, has anyone compiled valgrind for Windows?) >> valgrind is Linux only. > > I suspect it's not Linux-specific, but more gcc/g++ specific, and so > might be buildable on cygwin or mingw? If it is, then it might be usable > for Windows executables... > > J-S > -- > ______________________________________________________ > Jean-Sebastien Guay [email protected] > http://www.cm-labs.com/ > http://whitestar02.webhop.org/ > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
