[osg-users] SingleThreaded leading to whole application just running on one core

[Fabian Wiesel]

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.messerschmidt at 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 at lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org