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

Robert Osfield robert.osfield at gmail.com
Mon Sep 26 07:35:11 PDT 2016

HI Christoph,

On 26 September 2016 at 14:20, Christoph Weiss <weiss at wsoptics.de> wrote:
> I strongly disagree with the last sentence.  It is the most general use case
> possible:  using standard C++ features.

Please quite the hyperbole.  It does you no favours.

I am been writing C++ programs since 1992, been the project lead of
the OSG since 1999, the OSG has been started to embrace
mulit-ithreading in 2001.  I've interacted with thousands of
developers over the years. Strongly disagree with you may, but think
twice, between me and you who might know the most general use case for
the OSG?

I'm not some wet behind the ears engineer that knows nothing about
C++, threading or performance, these are things that make the OSG what
it is.

When I say we are talking about a very specific usage case it's
because in my 1i8 years as the project lead of the OSG it in my
experience it is a specific usage case rather than a common one.

> OSG's behavior changes the behavior of programs that, apart from OSG, rely
> solely on the C++ specification.  This is the most general problem possible,
> and far more important than the behavior of some specific libraries like
> pthreads or OpenThreads.

OK, lets get some facts down.

OpenThreads pre-dates C++11 by over a decade.

Yet it still doesn't offers MORE threading control and functionality
that native C++11 threads.

Does C++11 threads have support for processor affinity?  NO.

Processor affinity is essentially for any serious threading library.
So C++ threading support is a bit of fail in this respect.

YES you can add processor affinity via the native_handle.  You'll need
to dip into pthreads or other native threading libs for this, but this
rather defeats the point of having "portable" C++ threading.

If you own code example you make the ASSUMPTION that the affinity mask
of the thread creating your threads allows it to run on all threads.
Now if you've never done performance critical mult-threading the idea
of processor affinity may be alien, but it's not robust approach to

Why do you make this assumption about thread affinity?  Why don't you
set the thread affinity explicitly?

If you want to make your own code more robust remove the assumptions,
it'll make your own code more portable.

I've put in the effort to re-create the problem, I've found a number
of different solutions, none of which require any modifications to the
core OSG.  If there was a flaw on the OSG side then we wouldn't be
able to provide these solutions.


More information about the osg-users mailing list