Hi, > > Beyond mutexes, I am less skilled with thread synchronisation. But in > > other libraries like Qt sometimes the concept of thread local storage > > is used to separate resource access from parallel threads. Do you > > think this concept would be applicable to provide every thread with > > its own stream? Would this concept be more efficient compared to > > mutexes? I could imagine that every thread writes to an own stream > > which then calls the *same* osg::NotifyHandler subclass. This way, the > > notify handler would be responsible for thread-safeness again (as it > > is now). > > It's always problem of standard library. Creating output streams for every > thread is overkill and not safe either. What if internal implementation of > new streams will call some static internal write() function that won't be > threadsafe ?
Thanks for your hints again! It is a good point that under certain circumstances thread local streams would lack thread-safeness, too. > > I agree with the argument not to add extra mutexes. But what do you > > mean with "assumption that stream are thread safe"? Obviously neither > > the stream implementation of the Visual compiler under Windows nor the > > one of the GNU compiler under Lubuntu are thread-safe by nature. Do > > you know any such implementations or platforms or maybe compiler flags > > which fulfill this assumption? > > 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 ? > 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? I look forward to your feedback! Matthias Schütze, Germany _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
