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

Robert Osfield robert.osfield at gmail.com
Fri Sep 23 01:02:33 PDT 2016


On 23 September 2016 at 08:42, Christoph Weiss <weiss at wsoptics.de> wrote:
> Thank you so much for pointing this out, Pete.  So in
> ViewerBase::setUpThreading() osg decides the whole application should be
> confined to a single core.

When running SingleThread the OSG just sets the affinity of the
current thread.  That's it, that's all it's doing.

It does not explicitly change the affinity of any of threads created
by user applications.  I think what Pete found was under Linux is that
threads created after the set affinity to the current thread, all
threads created by that thread then inherit that affinity, which what
his code snippet looks to work around.

> Judging by your comment, this has already been discussed and not deemed a
> fault that should be fixed?

Changing something that was done by design because one class of usage
on one platform doesn't do exactly what they want.  There isn't a bug
to fix here.  It's sub-optimal behavior for certain types of
application usage on certain platforms.

>
> Also, I suppose there is no way to it portably?
> Thread::setProcessorAffinity() only allows restricting to a single core and
> has tons of ifdefs, so I guess I need to handle every cross compilation
> target individually?
>
> Thanks again, I really hope this behavior can be changed in a future
> release!

I haven't yet seen a reason to change the behaviour, it's not the case
that the behaviour is wrong for all users, it's not a bug.  Removing
the setting of affinity would leave the main thread to float around
and increase the changes of breaking cache.  The OSG is just trying to
do something sensible out of the box for most users.

In the case of Qt application, they should be run multi-theaded, for
all the native windowing systems the OSG support all work
multi-threaded without any problem.  Unfortunately Qt has created a
series of problems on the threading front that we've had to try and
work around, Qt then goes and moves the goal posts though between
releases. it's been a real pain to try and keep osgQt working well
over the years.  If you don't need a traditional 2D UI then it's
generally best to avoid Qt as it causes problems because it has it's
way of working that doesn't fit well with the needs of real-time
visualization.

Robert.



More information about the osg-users mailing list