Interesting claim on singletons ;)
I have to agree with Robert, singletons are an extremely useful tool but one
does have to understand they have limitations due to in general their static
nature and I also have disagree that pattern is broken, like anything they
can be missed used or over used, but I don't really see that in the OSG
core
The biggest issue I find is that so many programmers have no real
understanding of what the key word 'static' means to the life time of any
variable, whether a POD or a singleton and that's the real problem ( and I
know a lot of guys that are actually very good developers/programmers that
do not understand the lifetime), now you compound this issue on today's PC
that now finally support real multi- processors and threaded apps sadly
many yet simply do not have the back ground, experience, training again to
understand the life of a static in those arenas or developed apps that are
fully multi-processors and thread
This is good for old fossil idiots like myself and many on this list who cut
our vis-sim teeth on good old SGI and it wonderful multi-processors threaded
hardware/software environments, nothing like working with 32 processors, 14
graphics window outputs, 8 external various sim-engines feeding live in,
add in quite a few in DIS/HLA connections now those were the fun days ;)
Just in case I don’t mean to say y'all don’t understand , just that there a
lot that don't more than you would think and I find that scary ...
____________________________________________________________________________
__
Gordon Tomlinson
[email protected]
IM: [email protected]
www.vis-sim.com www.gordontomlinson.com
____________________________________________________________________________
__
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Robert
Osfield
Sent: Thursday, February 12, 2009 7:32 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] memory leak false positives on Windows
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
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
