Hi Matthias, On 14 June 2012 15:21, Matthias Schütze <matthi.schue...@googlemail.com> wrote: >> I agree with that too. Solution using custom osg::NotifyHandler with mutexes >> is easy and it dont have to be in osg core library, what about using >> NotifyHandler with mutexes if OSG_NOTIFY_LEVEL is set ?
Potentially we could provide a thread safe version of NotifyHandler as part of the core OSG, just not have it enabled by default so to prevent the performance consequences of it. >> Ok the problem will always persist, if someone use std::out directly, but >> that is not OSG problem .... > > Maybe, I missunderstand your argument. I'm sorry, if so. To clarify, > IMHO custom osg::NotifyHandler with mutexes seems to be *no* problem > at all. But as I noted earlier in this thread, heap corruption errors > are very likely a consequence of a race condition for the global > static instance of osg::NotifyStream (std::ostream). Those errors can > occur with every kind of notify handler, even empty ones and > thread-safe ones as well as osg::StandardNotifyHandler. > Because non-thread-safe implementations of std::ostream seems common > and OSG uses streams without protection, I think, the notification API > poses a wide problem, doesn't it? Theoretically, every OSG example > program executed on a multi-processor machine is affected by the race > condition by default. So, I would like to know, if this drawback is > commonly accepted in order to prefer OSG efficiency over guaranteed > thread-safeness? The OSG is used in many multi-threaded applications and the notification system as it is hasn't caused problems, is a debug system that mostly just sits behind the scenes doing nothing. If notification system was causing lots of problems then we'd be hearing about it much more, and the OSG wouldn't have got to 3.0 without tackling the issue. Given this I would expect having a thread safe NotifyHandler is likely to be niche tool going forward. W.r.t static initialization, this is something we need to sort out, and as long as there isn't a performance overhead in how we tackle it then I have no problem with it being the only code path for initialization of the singletons that manage the notification. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
