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
> <[email protected]> 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
>>
>> [email protected]
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
