On Wed, 2006-07-26 at 08:45 -0400, Daniel Larimer wrote: > One of many similar examples can be found here. > src/osg/Drawable.cpp:783 > > You suggested that using a singleton pattern may solve this issue and > I agree it could because the buffer wouldn't be allocated / updated until the > > first access; however, there may be some performance considerations such as:
Yes in combination with proper registration. Note that a static global is an unguarded singleton with C++ defined initialization rules. It is the registration of clients with the singleton that grants the necessary determinism that makes it safe in a MT environment. > - Extra check for NULL before every access (or init case) yeah ... if using the double-checked locking pattern. That patterns doesn't work so well in Java or the most modern C++ environements these days. Meyer has a good article on the C++ view of DCLP: http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf > - Extra function call on the stack > - You still have a race condition if the first access could come from > multiple threads which would put a mutex in the way A race condition would be a bug ;) The mutex is only checked on the very first access; again assuming double-checked locking. > At the very least you would have to centralize the many (20+?) static > objects so that you could control with one call when they all get initialized. That would work and it sounds like Robert is considering a new context object for that purpose. In the past I have done registration pretty much as you are suggesting; e.g. using an observer pattern to control initialization order in a dependency chain triggered by a static context object(s). > What are the downsides to the patch I submitted (submissions list) > with a DisplaySettingsListener object that solves this > problem The observer by itself doesn't solve the race condition when multiple threads are initializing a singleton though. You need both for a robust MT solution (or do eager initialization to avoid MT issues as recommended by Meyer et all). As Robert says most OSG users aren't doing multi-context work and so support is not critical for them. Note that increasing the default size to 32 (or previously 4 as Robert points out) is a form of eager initialization. The recent change to a default size of 1, making it more lazy initialization, actually increases the need for a MT lock. Regards, Marcus -- Mark Barnes COLLADA Project Lead, tel:+1.650.655.7342 Sony Computer Entertainment America http://research.scea.com _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
