Hi J-S, Your questions are quite legitimate. I'll try to answer them to my best knowledge.
1. The DllMain problem is quite well documented (cf. the MSDN links from my previous post). The thing is that an illegal use of DllMain is quite similar to a race condition. Most of the time, everything just seems to work. Our application has already about 10 threads up and running before osg.dll is being loaded, significantly increasing the chance of a deadlock. I would expect most OSG-based applications to do just fine as they start using OSG (and therefore osg.dll) when still single threaded. Because our application is quite multithreaded, it's not the first time we've uncovered thread-safety bugs in what are supposed to be quite stable libraries. Recently, we've just found a couple of thread-safety issues with LibCurl and OpenSSL (their developers have accepted these as genuine defects and are fixing these issues). Google found a few (not many) posts related to these issues, but due to the lack of proper investigations they often got dismissed. 2. Just going to http://en.wikipedia.org/wiki/Singleton_pattern you'll see that the first paragraph has already 6 anti-singleton references. A few other references I have at hand include: http://accu.org/index.php/journals/337 http://code.google.com/p/google-singleton-detector/wiki/WhySingletonsAreControversial http://blogs.msdn.com/scottdensmore/archive/2004/05/25/140827.aspx How can you replace singletons? If one still insists on using singletons, the first thing one can do to alleviate the problem is to provide init/destroy functions (note that they have to be thread-safe, re-entrant, and should be able to cope with multiple initializations). For example: initOsg() and destroyOsg() (or better: an object that calls init in its constructor and destroy in its destructor). These two functions control the lifetime of the whole library. This is a common approach, and for good reasons. Because you give the user control on the lifetime of the library, it effectively resolves the DllMain problem. A better way is not to use singletons at all. Just provide explicitly exposed objects and classes. The benefit is that you get rid of any hidden dependency. It also gives even more control to the user as far as the objects (and thus the library) lifetime is concerned. A lot of people (myself included) find singletons convenient because they do hide implicit dependency, which results in less code to be written. Unfortunately, I'm starting to think that it's a bad decision in most (all?) cases, especially in a library that is going to be used by others. As they force the user to give up lifetime control and dependency control, singletons just don't go well with some of C++ most common idioms (e.g. RAII). Furthermore, singletons tend to be a fuzzy concept. It states that you have a single instance of an object, but it does not state per what. With a naive "static Object" approach, you can end up having several singletons per thread (e.g. thread local storage), several singletons per process (one per DLL/EXE), and of course several singletons per applications (if there are several processes). Stretch it even more and imagine you're working on a distributed system. It's not uncommon to have several singletons when you're only supposed to have one (and it's very easy to fail to see this). Cheers, Tanguy -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jean-Sébastien Guay Sent: 29 July 2009 17:28 To: OpenSceneGraph Users Subject: Re: [osg-users] Deadlock when loading osg.dll, singletons are evil Hi Tanguy, > We've encountered several times a random deadlock that would happen when > starting our application. After some playing around, we've identified > the problem to be quite a subtle one. What you're describing makes sense in some way, but I have two questions: 1. Why have there not been more discussions about random deadlocks in the recent past? For example, we have not experienced anything resembling what you describe. I am not an expert in Win32 programming, so what you describe may well be true, but we haven't encountered this, and I'm pretty sure if it were such a widespread problem we'd have heard of it on this list before. Of course, that's not proof in itself that the issue is not there, but it's an indication that it might be something on your side rather than a widespread problem. 2. If singletons are bad practice as you say, what do you propose to replace them? I'm always a bit skeptical of sentences like "Google is full of papers [saying that singletons are broken]". People have a tendency to be extreme in their judgements, and if someone finds an instance where singletons give bad results, they will often start saying that they are bad in all cases (and inevitably post to their blog about it). It's a tool for a job, and the developer has to know when to use it and when not to. That's the developer's responsibility, not the tool's. I'm not saying that all uses of singletons in OSG are good ones (most obviously because I've probably not personally seen all of them) but singletons are useful (they give a single point of access to something - data, functionality) and that has to be replaced by something else if singletons have a downside in some/most/all(?) situations. 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
