Hi, > OSG is setting the affinity for some of its own threads, which is totally > legitimate.
Currently, I was not able to confirm it on my Mac. But I think, I observed such a behaviour in my application on Linux. But take it with a grain of salt, as it can be the result of some other side effects. I will try to test it the following days with a simple test program, unless you can point out a mistake, and save me the trouble. The following scenario sounds plausible to me: If you are setting the osgViewer::Viewer::setThreadingMode(SingleThreaded), and then calling Viewer::realize(), it will in turn call ViewerBase::setUpThreading() -> OpenThreads::SetProcessorAffinityOfCurrentThread(0); -> pthread_setaffinity_np(...) "pthread_setaffinity_np" will be called on the main thread, which is debatable, if it is its "OSGs own thread". The side effect is arising on Linux from the following (man page): > A new thread created by pthread_create(3) inherits a copy of its creator's > CPU affinity mask. So, all threads created either from the view or after the Viewer::realize() will only run on the main CPU. Given the following (pseudo-)program, I would expect the threads to run parallel on all processors, but likely they aren't on Linux. int main(int argc, char **argv) { std::vector<int> myvector(1024); osgViewer::Viewer viewer; viewer.setSceneData( node ); viewer.setThreadingModel(SingleThreaded); viewer.realize(); // calling ViewerBase::setUpThreading() -> OpenThreads::SetProcessorAffinityOfCurrentThread(0); -> pthread_setaffinity_np(...) // Create Threads for (int i = 0; i < 100; ++i) pthread_create(...) viewer.run() pthread_join(...); } Cheers, Fabian > On 24 Sep 2016, at 10:33, Sebastian Messerschmidt > <sebastian.messerschm...@gmx.de> wrote: > > Hi, > > Wow, before this escalates: OSG is setting the affinity for some of its own > threads, which is totally legitimate.And I totally agree, that it would be > nice to have an interface to control the core/wether affinity is used in > single-threaded mode except from having to subclass the viewer. > > If all other threads are forced to one core (as reported), by setting the > affinity of the osg-threads, it is clearly a bug and needs further inspection > . I've been working with OSG in a multi-threading environment for several > years and didn't experience problems so far however. > So creating a minimal example might help to find the problem, if there is one. > > Cheers > Sebastian >>> Affinity is set by default because the it will provide the best >>> performance for majority of OSG applications. This might be a >>> "terrible" reason for you, but the OSG development is motivated not by >>> just focusing on one class of users needs or preferences, default >>> settings we try to do the best for most OSG applications. >>> >> I have no particular desire to repeat the last discussion, but i'll say it >> again. >> >> Hardcoding CPU affinity is: >> a) unexpected >> b) a premature optimisation >> c) not consistent across platforms >> d) not easily reversible >> e) a performance killer outside of one specific application model. >> f) conflicting with other libraries that expect to set CPU affinity linked >> in the application >> >> >> It is a terrible idea, and doing it in the context of a library is just >> plain wrong. >> >> PS. Reason f) doesn't really exist because other libraries don't do this, >> for reasons a,b,c,d and e. >> >> ------------------ >> Read this topic online here: >> >> http://forum.openscenegraph.org/viewtopic.php?p=68716#68716 >> >> >> >> >> >> >> _______________________________________________ >> osg-users mailing list >> >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org