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

[Robert Osfield]

HI Fabien,

On 25 September 2016 at 22:52, Fabian Wiesel <fabian.wiesel at gmail.com> wrote:
> Yes, both cause the threads being distributed across the cores. That is
> probably also why initialising TBB early in main helps, as it creates a pool
> of worker threads. For my app, you can consider it solved.
> But don't you see a difficulty for OSG, if you cannot use any threading
> library without additonal setup code?

The only "difficulty" is when using a certain usage model when
threading, it's not a general issue.  The issue looks to be isolated
to the case where users set up threads after the viewer has been
realized.

I do agree that the inheritance of the affinity to child processes is
not ideal.  It's not something that I was aware of when adding the
processor affinity to osgViewer.  It would good to find a way to
prevent this implicit inheritance when not desired.

Setting the processor affinity is an important part of making a
real-time visualization application run at a solid 60Hz, having thread
jump from core to core breaks cache and can break frame, it's why the
code exists in osgViewer and why it doesn't make sense to just remove
it.

Being able to provide user control over affinity is something I've had
in mind for a number of years, with the decoupled way many of the OSG
threads are set up there isn't an easy 1:1 mapping that the users can
get there hands dirty with to set things i.e. the user doesn't
manually create the threads, the viewer, the databases, the video
plugins all create threads depending upon how they are configured and
whether they are required when certain types of data is loaded or not.
These threads that are created are assigned when possible to sensible
locations, but it's not idea.

If there was an easy and intuitive route to user control of thread
affinity it would have been implemented already.

Robert.