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

[Christoph Weiss]

Hi Robert,

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

This actually has a very bad side effect that I only noticed now.  Since 
it explicitly sets the affinity to core zero, any other application that 
does so will share its CPU entirely with it.  In particular if you start 
a SingleThread OSG application twice, it will share the core and have 
degraded performance.

I also wouldn't be surprised if the kernel favors core zero for things 
that aren't properly multithreaded, but I'm just guessing here, and 
maybe that's a thing of the past already, at least under linux.

I'm not even sure why setting the CPU affinity to a single core should 
improve performance at all unless the OS's scheduler performs poorly.

> 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.

Yes, they inherit the mask.  It would be quite similar if OSG set up a 
ulimit().

>> 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.

I agree, it's not a bug, it's a design choice.  However, it's a rather 
strict enforcement on the user.

> 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.

I totally understand that.  But I disagree with it being the most 
sensible choice ;)  Subclassing CompositeViewer is a good solution.  For 
me, it really does not make that much of a difference if the design is 
changed or not.  I'd be surprised if I was the last to run into this 
issue though and spend quite some time on figuring this out.

Apart from this, I think in general a library should not impose 
restrictions on the calling thread without it explicitly asking for 
them.  Suppose a library just decided to close file descriptors 0, 1, 2 
because it doesn't need them and can thus save some memory...

> 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.

Alas, we're quite stuck with Qt since we require a 2D UI.  But thanks 
for the information.

Christoph