Hi Robert, Thanks for your fast reply and revised code!
> osg::notify() is written on the assumption that stream are thread > safe, avoiding adding extra mutexes is desirable as the performance > would really suffer if we had to add them to all osg::notify() calls. 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 can see how that osg::initNotifyLevel() method might be problem if > multiple threads all call osg::notify() in parallel. To avoid this > perhaps a local proxy object to force initialization would be > sufficient so that it initialized prior to any calls to osg::notify(). I think, the proxy object to force early initialization is an important improvement to protect the init phase of the global static instance of osg::NotifyStream. But it cannot solve the whole problem, if the stream itself is not thread-safe when used with operator << from parallel threads. I quickly tested your code change with my sample program on my Windows machine: The heap corruption still occurs, indeed some time after the init phase. 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). Cheers, Matthias Schütze, Germany _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
