Hi All, Over the last week I've been looking into various issues with the DatabasePager, and one particular problem was major framerate stalls under Windows that occurred when multiple database paging threads were used (such as 8+ threads). Under Linux I had to up the number of threads to 64 to see as many frame breaks. I was investigating this issue in conjunction with a couple of engineers working under Windows and they pinpointed the Microsoft ostream implementation as the culprit.
The issue that the OSG the osg::notify() implementation uses ostream and when multiple threads try to write to it a ostream they contend for a mutex that Microsoft have used to implement ref counting. This issue even appears when the ostream is discarding the data, such as when an osg::notify(osg::INFO) is used in the OSG code, and the NotifySeverity is set to ignore INFO (the default). This means the diagnostics that the OSG has inbuilt in it stresses part of the Microsoft C++ standard library that was never designed to handle the needs of high performance apps... Since we can't fix Microsoft's shoddy coding practices, we are forced to tackle the problem on the OSG side. To this end I've introduce a new NOTIFY macro into include/osg/Notify that can be used in place of osg::notify which uses an if () statement to avoid using an stream code at all. The advantage of the macro is that we can introduce a further optimization for apps that want to ignore the diagnostic stream output completely (such as for a shipping app that you 100% believe will never have any bugs :-), and in this case we can get the macro to compile an "if (false) ostream<<.. " block which should compile away to nothing. I have gone through all the parts of the OSG that a paged database stresses at runtime and change their osg::notify() to NOTIFY to enable the more efficient discard of diagnostics. This will be little win for all platforms, but in the case of Windows it may well solve some big problems with scalability when apps are using lots of threads dealing with lots of data. Now I've just checked in my changes, I've touched a few dozen files converting osg::notify() to NOTIFY, which in itself is a pretty trivial change but the number of lines of code change is high so there is still a risk of me breaking the build or execution. Fingers crossed all platforms will just work as before, except without the frame breaks issues under Windows that we were seeing due to this MS ostream threading issue. Could users on all platforms test out svn/trunk and let me know how you get on. For Windows users it would be of particular interest to see if you can recreate issues with lots of OSG threads running causing frame breaks when paging. There are still other causes of frame breaks in apps, so please don't expect this change to solve all the challenges of writing high performance apps, but hopefully for this particular issue we'll have it kicked to touch. Thanks, Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
