Re: [osg-users] OpenThreads, scheduling, etc ... policies
Robert,
Attached is a copy of the PThread.cpp file from OSG 3.3.7 that I modified that
allows Linux systems to take full advantage of the pthread scheduling
parameters. The changes I made are all within the
#ifdef ALLOW_PRIORITY_SCHEDULING
define and the static int SetThreadSchedulingParams(Thread *thread)
function.
Feel free to pass this around to anyone that would like to review. comment
and/or test the changes when time permits. I am not
trying to rush anything, just figured I would go ahead and send
you what I am referring too, so it will be handy when time permits
you/(or your group) to take a look at it.
I am currently running with this change here and all our old existing OSG
applications still are running OK as well as are my new test applications that
take advantage of the changes.
One thing to note is that on at least my Linux system here, unless the user is
running with root privileges or their application as been changed to run with
root privileges the Linux kernel does not allow the application to run at
anything other than the default policy of SCHEDULE_OTHER and priority 0(zero),
no matter what they attempt to set. This is another protection that seems to
be in place to protect someone from accidentally causing a system problem.
Anything else that I can do to assist in getting this change implemented at
some point, please let me know.
Thank you for your time and consideration in this matter.
Cheers,
Curtis
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63650#63650
/* -*-c++-*- OpenThreads library, Copyright (C) 2002 - 2007 The Open Thread Group
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
//
// PThread.c++ - C++ Thread class built on top of posix threads.
// ~~~
#include stdlib.h
#include stdio.h
#include sys/types.h
#include unistd.h
#include pthread.h
#include limits.h
#if defined __linux__ || defined __sun || defined __APPLE__ || ANDROID
#include string.h
#include sys/time.h
#include sys/resource.h
#if !defined ANDROID
#include sys/unistd.h
#endif
#endif
#if defined(__sgi)
#include unistd.h
#endif
#if defined(__hpux)
#include sys/mpctl.h
#endif
#if defined(HAVE_THREE_PARAM_SCHED_SETAFFINITY) || defined(HAVE_TWO_PARAM_SCHED_SETAFFINITY)
#include sched.h
#endif
#if defined (__FreeBSD__) || defined (__APPLE__) || defined (__MACH__)
#include sys/types.h
#include sys/sysctl.h
#endif
#if defined(__ANDROID__)
#ifndef PAGE_SIZE
#define PAGE_SIZE 0x400
#endif
#endif
#include OpenThreads/Thread
#include PThreadPrivateData.h
#include iostream
using namespace OpenThreads;
#ifdef DEBUG
# define DPRINTF(arg) printf arg
#else
# define DPRINTF(arg)
#endif
#define ALLOW_PRIORITY_SCHEDULING 1
//-
// Initialize the static unique ids.
//
int PThreadPrivateData::nextId = 0;
//-
// Initialize thread master priority level
//
Thread::ThreadPriority Thread::s_masterThreadPriority =
Thread::THREAD_PRIORITY_DEFAULT;
bool Thread::s_isInitialized = false;
pthread_key_t PThreadPrivateData::s_tls_key;
struct ThreadCleanupStruct
{
OpenThreads::Thread *thread;
Atomic *runflag;
};
//-
// This cleanup handler is necessary to ensure that the thread will cleanup
// and set its isRunning flag properly.
//
void thread_cleanup_handler(void *arg)
{
ThreadCleanupStruct *tcs = static_castThreadCleanupStruct *(arg);
tcs-thread-cancelCleanup();
(*(tcs-runflag)).exchange(0);
}
//-
// Class to support some static methods necessary for pthread's to work
// correctly.
//
namespace OpenThreads
{
class ThreadPrivateActions
{
//-
// We're friendly to Thread, so it can issue the methods.
//
friend class Thread;
private:
//-
// pthreads standard start routine.
//
static void *StartThread(void *data)
{
Thread *thread = static_castThread *(data);
PThreadPrivateData *pd =
static_castPThreadPrivateData *(thread-_prvData);
Re: [osg-users] OpenThreads, scheduling, etc ... policies
Hi, I would like to revisit this topic again as I see that even in the current trunk(3.3.8) as of this date May 04, 2015, the linux platform is still crippled inside of Openthreads/PThread API, from running priority/real-time scheduling policies. I will like to open a discussion about removing the code that is currently crippling the Linux platform as I do not see any reason at this date time to leave it this way. When properly used, as on any other platform, the currently crippled threading policies work properly on the Linux platform. ... Thank you! Cheers, Curtis -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=63625#63625 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads, scheduling, etc ... policies
Hi Curtis, On 4 May 2015 at 14:32, Curtis Rubel cru...@compro.net wrote: I would like to revisit this topic again as I see that even in the current trunk(3.3.8) as of this date May 04, 2015, the linux platform is still crippled inside of Openthreads/PThread API, from running priority/real-time scheduling policies. I will like to open a discussion about removing the code that is currently crippling the Linux platform as I do not see any reason at this date time to leave it this way. When properly used, as on any other platform, the currently crippled threading policies work properly on the Linux platform. I have just gone on the forum to try and an piece together what you might be talking about, but there isn't enough of trail for me to clearly know what code is at issue. Could you please create a small example that illustrates the problem, and a clear explanation of what you think needs changing. For the OSG-3.4 release the most important thing for me is making sure the software build across a full range of linux variants and works stabling. I'm happy for the OSG to go to OSG-3.4 as is, so any additionally changes have to be low risk on build and runtime stability. As a general note, calling things crippled won't change how I view the issue. Many people use the OSG fully threaded under Linux without problems and have done so for years, having some niche feature not work exactly how you expect it for your specific build combination isn't crippled. If there is a bug and it can be reproduce, fixed in a way that doesn't risk build and runtime stability I'll be happy, you don't need the hyperbole. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads, scheduling, etc ... policies
Robert,
When I mentioned crippled, I did not mean that as a bad or derogatory
comment. Maybe saying something like intentionally disabled would have
been a better choice of words, my apologies if my wording offended anyone in
any way.
Basic threading is working fine under Linux. If the user however wants to
take advantage of all of the available threading policies and priorities now
available to them they cannot. I think that this is just possibly just due to
this section of Openthreads not being updated when these features were fully
implemented and properly working on the linux platform.
Here is a code excerpt of the SetThreadSchedulingParams
function call within OpenThreads/phhreads/PThread.cpp
Code:
//--
// Set thread scheduling parameters. Unfortunately on Linux, there's no
// good way to set this, as pthread_setschedparam is mostly a no-op.
//
static int SetThreadSchedulingParams(Thread *thread)
{
int status = 0;
#ifdef ALLOW_PRIORITY_SCHEDULING // [
if(sysconf(_POSIX_THREAD_PRIORITY_SCHEDULING))
{
int th_policy;
int max_priority, nominal_priority, min_priority;
sched_param th_param;
pthread_getschedparam(thread-getProcessId(),
th_policy, th_param);
#ifndef __linux__
switch(thread-getSchedulePolicy())
{
case Thread::THREAD_SCHEDULE_FIFO:
th_policy = SCHED_FIFO;
break;
case Thread::THREAD_SCHEDULE_ROUND_ROBIN:
th_policy = SCHED_RR;
break;
case Thread::THREAD_SCHEDULE_TIME_SHARE:
th_policy = SCHED_OTHER;
break;
default:
#ifdef __sgi
th_policy = SCHED_RR;
#else
th_policy = SCHED_FIFO;
#endif
break;
};
#else
th_policy = SCHED_OTHER; // Must protect linux from realtime.
#endif
#ifdef __linux__
max_priority = 0;
min_priority = 20;
nominal_priority = (max_priority + min_priority)/2;
#else
max_priority = sched_get_priority_max(th_policy);
min_priority = sched_get_priority_min(th_policy);
nominal_priority = (max_priority + min_priority)/2;
#endif
switch(thread-getSchedulePriority())
{
case Thread::THREAD_PRIORITY_MAX:
th_param.sched_priority = max_priority;
break;
case Thread::THREAD_PRIORITY_HIGH:
th_param.sched_priority = (max_priority +
nominal_priority)/2;
break;
case Thread::THREAD_PRIORITY_NOMINAL:
th_param.sched_priority = nominal_priority;
break;
case Thread::THREAD_PRIORITY_LOW:
th_param.sched_priority = (min_priority +
nominal_priority)/2;
break;
case Thread::THREAD_PRIORITY_MIN:
th_param.sched_priority = min_priority;
break;
default:
th_param.sched_priority = max_priority;
break;
}
status = pthread_setschedparam(thread-getProcessId(),
th_policy,
th_param);
if(getenv(OUTPUT_THREADLIB_SCHEDULING_INFO) != 0)
PrintThreadSchedulingInfo(thread);
}
#endif // ] ALLOW_PRIORITY_SCHEDULING
return status;
};
You can see in this excerpt that on Linux platforms the code to allow you to
select any of the available threading policies is allowed on all platforms but
linux. Linux is hard-coded to set the SCHED_OTHER policy.
The other sections of the code excerpt limit the range of priorities allowed to
between 0 and 20, when linux currently has a range of 0 - 99, 99 being the
highest priority allowed. The associated calls to sched_get_priority_max and
sched_get_priority_min are not allowed on the linux platform.
I will be happy to provide you with a sample application if you still would
like to have one, but I think the ifndef's in the code will let you see what I
am referring too.
Again I apologize if I offended anyone, that was not my intention.
...
Thank you!
Cheers,
Curtis
Code:
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63627#63627
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads, scheduling, etc ... policies
Hi Curtis,
There has to be a historical reason for need for the #ifndef __linux__
around the thread scheduling assignment. As I'm not the author of
this block of code I can only check the code and svn log's. I'm
currently working on a complex bug fix on another area of the OSG so
can't dive into a new area of code right now.
Given there has to be a reason for the special handling under Linux we
can't just remove the block and hope for the best. It may be possible
to specialize the #ifndef to allow certain combinations for linux to
work, but we'd need to track down which combinations we might expect
to work and which ones might not so we can determine the right type of
checks to apply. This is why the history is important. I'm guessing
there older versions of Linux didn't fully implement pthreads/pthread
extensions. I have to defer to others in this department though, as I
don't have experience with all variants of pthreads on linux though
time.
Robert.
On 4 May 2015 at 15:26, Curtis Rubel cru...@compro.net wrote:
Robert,
When I mentioned crippled, I did not mean that as a bad or derogatory
comment. Maybe saying something like intentionally disabled would have
been a better choice of words, my apologies if my wording offended anyone in
any way.
Basic threading is working fine under Linux. If the user however wants to
take advantage of all of the available threading policies and priorities now
available to them they cannot. I think that this is just possibly just due
to this section of Openthreads not being updated when these features were
fully implemented and properly working on the linux platform.
Here is a code excerpt of the SetThreadSchedulingParams
function call within OpenThreads/phhreads/PThread.cpp
Code:
//--
// Set thread scheduling parameters. Unfortunately on Linux, there's no
// good way to set this, as pthread_setschedparam is mostly a no-op.
//
static int SetThreadSchedulingParams(Thread *thread)
{
int status = 0;
#ifdef ALLOW_PRIORITY_SCHEDULING // [
if(sysconf(_POSIX_THREAD_PRIORITY_SCHEDULING))
{
int th_policy;
int max_priority, nominal_priority, min_priority;
sched_param th_param;
pthread_getschedparam(thread-getProcessId(),
th_policy, th_param);
#ifndef __linux__
switch(thread-getSchedulePolicy())
{
case Thread::THREAD_SCHEDULE_FIFO:
th_policy = SCHED_FIFO;
break;
case Thread::THREAD_SCHEDULE_ROUND_ROBIN:
th_policy = SCHED_RR;
break;
case Thread::THREAD_SCHEDULE_TIME_SHARE:
th_policy = SCHED_OTHER;
break;
default:
#ifdef __sgi
th_policy = SCHED_RR;
#else
th_policy = SCHED_FIFO;
#endif
break;
};
#else
th_policy = SCHED_OTHER; // Must protect linux from realtime.
#endif
#ifdef __linux__
max_priority = 0;
min_priority = 20;
nominal_priority = (max_priority + min_priority)/2;
#else
max_priority = sched_get_priority_max(th_policy);
min_priority = sched_get_priority_min(th_policy);
nominal_priority = (max_priority + min_priority)/2;
#endif
switch(thread-getSchedulePriority())
{
case Thread::THREAD_PRIORITY_MAX:
th_param.sched_priority = max_priority;
break;
case Thread::THREAD_PRIORITY_HIGH:
th_param.sched_priority = (max_priority +
nominal_priority)/2;
break;
case Thread::THREAD_PRIORITY_NOMINAL:
th_param.sched_priority = nominal_priority;
break;
case Thread::THREAD_PRIORITY_LOW:
th_param.sched_priority = (min_priority +
nominal_priority)/2;
break;
case Thread::THREAD_PRIORITY_MIN:
th_param.sched_priority = min_priority;
break;
default:
th_param.sched_priority = max_priority;
break;
}
status = pthread_setschedparam(thread-getProcessId(),
th_policy,
th_param);
if(getenv(OUTPUT_THREADLIB_SCHEDULING_INFO) != 0)
PrintThreadSchedulingInfo(thread);
}
#endif // ] ALLOW_PRIORITY_SCHEDULING
return status;
};
You can see in this excerpt that on Linux platforms the code to allow you to
select any of the available threading policies is allowed on all platforms
but
Re: [osg-users] OpenThreads, scheduling, etc ... policies
Robert, There is already a define around all the priority scheduling calls to protect people from accidentally using them: #ifdef ALLOW_PRIORITY_SCHEDULING Which seems to have to be defined in the calling program as I cannot find this any place inside of OSG other than the pthreads source. Maybe this would suffice for now to protect these calls. I am going to suspect that few Linux users are defining this since the only reason to do so would be to use the calls that are currently ifdef'd out looking at the code inside of the ALLOW_PRIORITY_SCHEDULING define. I agree with you about Linux not originally supporting the full suite of the pthread extensions. Linux has come a long way in recent years. We have been using these real-time pthread scheduling parameters though for at least 5 or 6 years now on our other Linux applications that do not need OpenSceneGraph support. So the support on Linux has been there for awhile. Is it possible to contact the original author on this subject, if so who would I contact? Hopefully we will get some more comments on this topic for the OSG community... ... Thank you! Cheers, Curtis -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=63629#63629 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads, scheduling, etc ... policies
HI Nick, On 5 May 2014 20:07, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Curtis implemented the same code with pthreads (attached) which seam to work, so it is definitely a bug in OpenThreads (for linux only, Windows implementation seam to be working). Just FYI I am currently focused on some other complex work and don't really have spare brain capacity to add another item right now. Threading affinity used to work under Linux when OpenThreads was created, I guess something must have changed in the pthread implementation that has changed how things need to be managed or perhaps a regression has happened on the OSG side. As I don't have the capacity right now could others investigate further? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads, scheduling, etc ... policies
Hi Robert, I spent few hours on this and I have things to report. First, there are code mods I did to fix it actually, but, there is a comment like // Must protect linux from realtime., PThread.cpp around ln: 323. I have mods to submit but can not do that yet since there are issue with the config. Seam like these are not getting defined on my 64bit Ubuntu (I am not a config guru so I need help from others on this): __linux, __linux__, HAVE_THREE_PARAM_SCHED_SETAFFINITY, HAVE_TWO_PARAM_SCHED_SETAFFINITY ... etc. and all of these that should be set from the pthreads/CMakeLists.txt but are not. Also ALLOW_PRIORITY_SCHEDULING is not set at all. I had to hard code these defines to make it work but someone need to look in the configuration of pthread or at least give some hints so I can dig into Thanks for the time anyway you are showing on this topic Nick On Tue, May 6, 2014 at 10:21 AM, Robert Osfield robert.osfi...@gmail.comwrote: HI Nick, On 5 May 2014 20:07, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Curtis implemented the same code with pthreads (attached) which seam to work, so it is definitely a bug in OpenThreads (for linux only, Windows implementation seam to be working). Just FYI I am currently focused on some other complex work and don't really have spare brain capacity to add another item right now. Threading affinity used to work under Linux when OpenThreads was created, I guess something must have changed in the pthread implementation that has changed how things need to be managed or perhaps a regression has happened on the OSG side. As I don't have the capacity right now could others investigate further? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads, scheduling, etc ... policies
Hi Nick, On 6 May 2014 16:25, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: I spent few hours on this and I have things to report. First, there are code mods I did to fix it actually, but, there is a comment like // Must protect linux from realtime., PThread.cpp around ln: 323. I have mods to submit but can not do that yet since there are issue with the config. Seam like these are not getting defined on my 64bit Ubuntu (I am not a config guru so I need help from others on this): __linux, __linux__, HAVE_THREE_PARAM_SCHED_SETAFFINITY, HAVE_TWO_PARAM_SCHED_SETAFFINITY ... etc. and all of these that should be set from the pthreads/CMakeLists.txt but are not. Also ALLOW_PRIORITY_SCHEDULING is not set at all. I had to hard code these defines to make it work but someone need to look in the configuration of pthread or at least give some hints so I can dig into CMake should be automatically detecting these features, the following OpenSceneGraph/src/OpenThreads/pthreads/CMakeLists.txt portion should be doing this: CHECK_FUNCTION_EXISTS(pthread_yield HAVE_PTHREAD_YIELD) .. CHECK_FUNCTION_EXISTS(pthread_getconcurrency HAVE_PTHREAD_GETCONCURRENCY) .. CHECK_FUNCTION_EXISTS(pthread_setconcurrency HAVE_PTHREAD_SETCONCURRENCY) .. CHECK_FUNCTION_EXISTS(pthread_setaffinity_np HAVE_PTHREAD_SETAFFINITY_NP) For these to pass then functions pthread_yield, pthread_getconcurrency, pthread_setconcurrency and pthread_setaffinity_np will need to be present in the system pthreads.h header. If you run make VERBOSE=1 you should see the -D entries assocated with these cmake variables. What I see on my system when I do this is: Building CXX object src/OpenThreads/pthreads/CMakeFiles/OpenThreads.dir/__/common/Atomic.o cd /home/robert/OpenSceneGraph/src/OpenThreads/pthreads /usr/bin/c++ -DHAVE_PTHREAD_CANCEL -DHAVE_PTHREAD_SETCANCELSTATE -DHAVE_PTHREAD_TESTCANCEL -DHAVE_SCHED_YIELD -DHAVE_THREE_PARAM_SCHED_SETAFFINITY -DOPENTHREADS_EXPORTS -DOpenThreads_EXPORTS -D_GNU_SOURCE -Wall -Wparentheses -Wno-long-long -Wno-import -pedantic -Wreturn-type -Wmissing-braces -Wunknown-pragmas -Wunused -O3 -DNDEBUG -fPIC -I/home/robert/OpenSceneGraph/include -o CMakeFiles/OpenThreads.dir/__/common/Atomic.o -c /home/robert/OpenSceneGraph/src/OpenThreads/common/Atomic.cpp Linking CXX shared library ../../../lib/libOpenThreads.so What do you get if you do a build with VEROSE=1? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads, scheduling, etc ... policies
Hi Robert, My first problem was that I had selected the option to build OpenThreads with QT in cmake for some reason. So I rebuilt with this option off.. My apologies on that issue... At least it is now using the pthreads section properly. However, as Nick stated in his post, the openthreads code to allow me to select a scheduling policy other than OTHER has been ifdef'd out for __linux__ even though these options are available on Linux. This is also affecting the ability to set a proper thread priority value. So while Nick and I can fix this by removing the __linux__ checks, I would like to see if anyone knows why this was put in there in the first place so that we do not possibly break something else as we are attempting to fix the issues that we are seeing. ... Thank you! Cheers, Curtis -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59289#59289 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads, scheduling, etc ... policies
Hi Robert, here is the log cd /home/ubuntu/OpenSceneGraph/src/OpenThreads/pthreads /usr/bin/c++ -DHAVE_PTHREAD_CANCEL -DHAVE_PTHREAD_SETCANCELSTATE -DHAVE_PTHREAD_TESTCANCEL -DHAVE_SCHED_YIELD -DHAVE_THREE_PARAM_SCHED_SETAFFINITY -DOPENTHREADS_EXPORTS -DOpenThreads_EXPORTS -D_GNU_SOURCE -Wall -Wparentheses -Wno-long-long -Wno-import -pedantic -Wreturn-type -Wmissing-braces -Wunknown-pragmas -Wunused -O3 -DNDEBUG -fPIC -I/home/ubuntu/OpenSceneGraph/include As I mentioned earlier ALLOW_PRIORITY_SCHEDULING is not set anywhere - I examined the CMakeLists.txt for pthreads. But it is used in the code right in places where the priority is set. Also these __linux and __linux__ .. are these system wide defined by default? I am using QT Creator as an editor and seeing these grayed out Thanks again Nick On Tue, May 6, 2014 at 6:08 PM, Curtis Rubel cru...@compro.net wrote: Hi Robert, My first problem was that I had selected the option to build OpenThreads with QT in cmake for some reason. So I rebuilt with this option off.. My apologies on that issue... At least it is now using the pthreads section properly. However, as Nick stated in his post, the openthreads code to allow me to select a scheduling policy other than OTHER has been ifdef'd out for __linux__ even though these options are available on Linux. This is also affecting the ability to set a proper thread priority value. So while Nick and I can fix this by removing the __linux__ checks, I would like to see if anyone knows why this was put in there in the first place so that we do not possibly break something else as we are attempting to fix the issues that we are seeing. ... Thank you! Cheers, Curtis -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59289#59289 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads, scheduling, etc ... policies
Hi Nick, On 6 May 2014 17:26, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Hi Robert, here is the log cd /home/ubuntu/OpenSceneGraph/src/OpenThreads/pthreads /usr/bin/c++ -DHAVE_PTHREAD_CANCEL -DHAVE_PTHREAD_SETCANCELSTATE -DHAVE_PTHREAD_TESTCANCEL -DHAVE_SCHED_YIELD -DHAVE_THREE_PARAM_SCHED_SETAFFINITY -DOPENTHREADS_EXPORTS -DOpenThreads_EXPORTS -D_GNU_SOURCE -Wall -Wparentheses -Wno-long-long -Wno-import -pedantic -Wreturn-type -Wmissing-braces -Wunknown-pragmas -Wunused -O3 -DNDEBUG -fPIC -I/home/ubuntu/OpenSceneGraph/include This mean CMake is detecting the features. As I mentioned earlier ALLOW_PRIORITY_SCHEDULING is not set anywhere - I examined the CMakeLists.txt for pthreads. But it is used in the code right in places where the priority is set. Also these __linux and __linux__ .. are these system wide defined by default? I am using QT Creator as an editor and seeing these grayed out Curious. I did a quick search and came across the page: sourceforge.net/p/predef/wiki/OperatingSystems/ The suggests __linux is obsolete, so __linux__ should be the one we should use. I replaced the one instance where __linux was used with the __linux__ version and checked this in to svn/trunk. The ALLOW_PRIORITY_SCHEDULING one is more odd. I can't find a reference in the ALLOW_PRIORITY_SCHEDULING in anywhere in the OpenThreads code base apart from where it's used in OpenThreads/pthreads, so it's used by not defined. I seems like Cmake should be added this option via another -D entry but isn't. I don't recall the submission that introduced this, it might be worth stepping back through the svn logs to see the author of this specific addition and bring them into the discussion. It could be that this was missed with integration of Cmake or similar changes. FYI, I'm not the author of OpenThreads, just ended up the defacto caretaker as the original author stepped back. This means I'm similar situation to others - I read the code, work out what it supposed to do and make correction or merge fixes that look appropriate. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads, scheduling, etc ... policies
Nick, __linux__ is defined someplace in the gcc compiler as it finds the current arch and os, etc., installed. you can: cpp -dM /dev/null and see all the gcc defines output. I see that __linux is still there as well, at least for the time being. ALLOW_PRIORITY_SCHEDULING, however seems to be an OpenThreads specific define. ... Thank you! Cheers, Curtis -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59293#59293 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads, scheduling, etc ... policies
interesting ... my ubuntu has __unix and __unix__ instead of linux. Nick On Tue, May 6, 2014 at 7:01 PM, Curtis Rubel cru...@compro.net wrote: Nick, __linux__ is defined someplace in the gcc compiler as it finds the current arch and os, etc., installed. you can: cpp -dM /dev/null and see all the gcc defines output. I see that __linux is still there as well, at least for the time being. ALLOW_PRIORITY_SCHEDULING, however seems to be an OpenThreads specific define. ... Thank you! Cheers, Curtis -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59293#59293 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads, scheduling, etc ... policies
Hi Nick, On 6 May 2014 18:11, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: interesting ... my ubuntu has __unix and __unix__ instead of linux. I have 64bit Kubuntu 14.04 installed here and when I follow Curtis's suggestion I get: $ cpp -dM /dev/null | grep __linux #define __linux 1 #define __linux__ 1 Which version of Ubunutu are you using? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads, scheduling, etc ... policies
Ubuntu 13.04 raring got it from the store installed on the laptop I bought in a rush :-) Nick On Tue, May 6, 2014 at 7:17 PM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Nick, On 6 May 2014 18:11, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: interesting ... my ubuntu has __unix and __unix__ instead of linux. I have 64bit Kubuntu 14.04 installed here and when I follow Curtis's suggestion I get: $ cpp -dM /dev/null | grep __linux #define __linux 1 #define __linux__ 1 Which version of Ubunutu are you using? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads, scheduling, etc ... policies
Hi, Checked out the latest trunk version myself and I am still having the same issues here with the OpenThread calls and the example code I sent to Nick. We are running OpenSuse 12.3 64-bit here. The calls all return good status. In fact the getSchedulePolicy and the getSchedulePriority return the same level that was set, but the linux system calls do not show any change in the threads priority, scheduling policy or affinity. Tried running the example as normal user and the root user and get the same exact results so does not seem to be any sort of issue with priviledges at this point either. Thank you! Cheers, Curtis -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59262#59262 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads, scheduling, etc ... policies
Hi Robert,
Curtis implemented the same code with pthreads (attached) which seam to
work, so it is definitely a bug in OpenThreads (for linux only, Windows
implementation seam to be working). Just FYI
Nick
On Mon, May 5, 2014 at 3:23 PM, Curtis Rubel cru...@compro.net wrote:
Hi,
Checked out the latest trunk version myself and I am still having the same
issues here with the OpenThread calls and the example code I sent to Nick.
We are running OpenSuse 12.3 64-bit here.
The calls all return good status. In fact the getSchedulePolicy and the
getSchedulePriority return the same level that was set, but the linux
system calls do not show any change in the threads priority, scheduling
policy or affinity.
Tried running the example as normal user and the root user and get the
same exact results so does not seem to be any sort of issue with
priviledges at this point either.
Thank you!
Cheers,
Curtis
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=59262#59262
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
trajce nikolov nick
/* -*-c++-*- Copyright (C) 2010 Wang Rui wangray84 at gmail dot com
* OpenSceneGraph Beginners Guide
* Using a separate thread for supplying data to a node in the main process
*/
#include osg/Geode
#include osgDB/ReadFile
#include osgText/Text
#include osgViewer/Viewer
#include iostream
//#define OPENTHREADS_ENABLED
#ifdef OPENTHREADS_ENABLED
class DataReceiverThread : public OpenThreads::Thread
{
public:
virtual int cancel()
{
_done = true;
while( isRunning() ) YieldCurrentThread();
return 0;
}
virtual void run()
{
_done = false;
_dirty = true;
do
{
YieldCurrentThread();
char ch;
std::cin.get(ch);
printf([%c][%d] , ch, ch);
switch (ch)
{
case 0: break; // We don¡¯t want ¡®\0¡¯ to be added
case 9: _done = true; break; // Tab = 9
default: addToContent(ch); break;
}
} while( !_done );
}
void addToContent( int ch )
{
OpenThreads::ScopedLockOpenThreads::Mutex lock(_mutex);
_content += ch;
_dirty = true;
}
bool getContent( std::string str )
{
OpenThreads::ScopedLockOpenThreads::Mutex lock(_mutex);
if ( _dirty )
{
str += _content;
_dirty = false;
return true;
}
return false;
}
protected:
OpenThreads::Mutex _mutex;
std::string _content;
bool _done;
bool _dirty;
};
#else
#include pthread.h
class DataReceiverThread
{
public:
DataReceiverThread()
{
_mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_attr_init(custom_sched_attr);
CPU_ZERO(cpuset);
CPU_SET(7,cpuset);
pthread_attr_setscope(custom_sched_attr, PTHREAD_SCOPE_SYSTEM);
pthread_attr_setinheritsched(custom_sched_attr, PTHREAD_EXPLICIT_SCHED);
pthread_attr_setschedpolicy(custom_sched_attr, SCHED_FIFO);
fifo_max_prio = sched_get_priority_max(SCHED_FIFO);
fifo_min_prio = sched_get_priority_min(SCHED_FIFO);
fifo_mid_prio = (fifo_min_prio + fifo_max_prio)/2;
fifo_param.sched_priority = fifo_mid_prio;
pthread_attr_setschedparam(custom_sched_attr, fifo_param);
}
~DataReceiverThread();
virtual int cancel()
{
_done = true;
sched_yield();
return 0;
}
virtual void run()
{
_done = false;
_dirty = true;
do
{
sched_yield();
char ch;
std::cin.get(ch);
printf([%c][%d] , ch, ch);
switch (ch)
{
case 0: break; // We don¡¯t want ¡®\0¡¯ to be added
case 9: _done = true; break; // Tab = 9
default: addToContent(ch); break;
}
} while( !_done );
}
bool StartInternalThread()
{
bool status;
if(pthread_create(_thread, custom_sched_attr, DataRcvrThreadFunc, this) == 0)
status = true;
else
status = false;
if(status)
status = pthread_setaffinity_np(_thread, sizeof(cpu_set_t), cpuset);
return status;
}
void addToContent( int ch )
{
pthread_mutex_lock(_mutex);
_content += ch;
_dirty = true;
pthread_mutex_unlock(_mutex);
}
bool getContent( std::string str )
{
if ( _dirty )
{
pthread_mutex_lock(_mutex);
str += _content;
_dirty = false;
pthread_mutex_unlock(_mutex);
return true;
}
return false;
}
protected:
pthread_t _thread;
pthread_mutex_t _mutex;
pthread_attr_t custom_sched_attr;
struct
Re: [osg-users] OpenThreads, scheduling, etc ... policies
Hi Nick, Last month I checked in a fix for this issue, could you try out svn/trunk to see if it things work now as you were expecting? Robert. On 1 May 2014 18:49, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Hi Community my client found interesting behaviour on OpenThreads under 64bit OpenSuSE linux. It seam none of the calls like setSchedulePolicy, setProcessorAffinity and setSechedulePriority of OpenThreads::Thread are working. After running a code, they all return 0 (success) but after inspecting the threads in some tools, they show they are not set as expected. So I gave it a try on Ubuntu 64bit. On my linux box none werle working - all returned -1 (failure). Attached is simple code from Rui's book that ilustrate the problem. Any help is appreciated ! Also, the OSG version tested is 3.3.1 Nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads, scheduling, etc ... policies
Thanks Robert. I am going to try it right away. Just to clarify, this is the address of the current trunk, right? http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk On Fri, May 2, 2014 at 11:56 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Nick, Last month I checked in a fix for this issue, could you try out svn/trunk to see if it things work now as you were expecting? Robert. On 1 May 2014 18:49, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Hi Community my client found interesting behaviour on OpenThreads under 64bit OpenSuSE linux. It seam none of the calls like setSchedulePolicy, setProcessorAffinity and setSechedulePriority of OpenThreads::Thread are working. After running a code, they all return 0 (success) but after inspecting the threads in some tools, they show they are not set as expected. So I gave it a try on Ubuntu 64bit. On my linux box none werle working - all returned -1 (failure). Attached is simple code from Rui's book that ilustrate the problem. Any help is appreciated ! Also, the OSG version tested is 3.3.1 Nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads, scheduling, etc ... policies
On 2 May 2014 10:12, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Thanks Robert. I am going to try it right away. Just to clarify, this is the address of the current trunk, right? http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk Yep, that is correct. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads, scheduling, etc ... policies
Hi Robert, I just build the latest from the trunk - revision 14188, and no changes. Still geting failures (-1) on these calls. But on Windows it works well. Any ideas? Could you give it a shot to the attached file, it is selfcontained Thanks a bunch! Nick On Fri, May 2, 2014 at 12:18 PM, Robert Osfield robert.osfi...@gmail.comwrote: On 2 May 2014 10:12, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Thanks Robert. I am going to try it right away. Just to clarify, this is the address of the current trunk, right? http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk Yep, that is correct. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenThreads, scheduling, etc ... policies
Hi Community
my client found interesting behaviour on OpenThreads under 64bit OpenSuSE
linux. It seam none of the calls like setSchedulePolicy,
setProcessorAffinity and setSechedulePriority of OpenThreads::Thread are
working. After running a code, they all return 0 (success) but after
inspecting the threads in some tools, they show they are not set as
expected.
So I gave it a try on Ubuntu 64bit. On my linux box none werle working -
all returned -1 (failure). Attached is simple code from Rui's book that
ilustrate the problem.
Any help is appreciated ! Also, the OSG version tested is 3.3.1
Nick
/* -*-c++-*- Copyright (C) 2010 Wang Rui wangray84 at gmail dot com
* OpenSceneGraph Beginners Guide
* Using a separate thread for supplying data to a node in the main process
*/
#include osg/Geode
#include osgDB/ReadFile
#include osgText/Text
#include osgViewer/Viewer
#include iostream
class DataReceiverThread : public OpenThreads::Thread
{
public:
DataReceiverThread()
: OpenThreads::Thread()
{
int status = setProcessorAffinity(0);
printf(setProcessorAffinity status: %d\n, status);
}
virtual int cancel()
{
_done = true;
while( isRunning() ) YieldCurrentThread();
return 0;
}
virtual void run()
{
_done = false;
_dirty = true;
do
{
YieldCurrentThread();
char ch;
std::cin.get(ch);
printf([%c][%d] , ch, ch);
switch (ch)
{
case 0: break; // We donĄŻt want ĄŽ\0ĄŻ to be added
case 9: _done = true; break; // Tab = 9
default: addToContent(ch); break;
}
} while( !_done );
}
void addToContent( int ch )
{
OpenThreads::ScopedLockOpenThreads::Mutex lock(_mutex);
_content += ch;
_dirty = true;
}
bool getContent( std::string str )
{
OpenThreads::ScopedLockOpenThreads::Mutex lock(_mutex);
if ( _dirty )
{
str += _content;
_dirty = false;
return true;
}
return false;
}
protected:
OpenThreads::Mutex _mutex;
std::string _content;
bool _done;
bool _dirty;
};
class UpdateTextCallback : public osg::Drawable::UpdateCallback
{
public:
UpdateTextCallback(DataReceiverThread* rcvrthrd) : rcvrthread(rcvrthrd)
{}
virtual void update( osg::NodeVisitor* nv, osg::Drawable* drawable )
{
osgText::Text* text = static_castosgText::Text*( drawable );
if ( text )
{
std::string str(# );
//if ( DataReceiverThread::instance()-getContent(str) )
if ( rcvrthread-getContent(str) )
text-setText( str );
}
}
DataReceiverThread* rcvrthread;
};
int main( int argc, char** argv )
{
int status;
osg::ref_ptrosgText::Text text = new osgText::Text;
text-setFont( fonts/arial.ttf );
text-setAxisAlignment( osgText::TextBase::SCREEN );
text-setDataVariance( osg::Object::DYNAMIC );
text-setInitialBound( osg::BoundingBox(osg::Vec3(), osg::Vec3(400.0f, 20.0f, 20.0f)) );
DataReceiverThread* rcvrthread = new DataReceiverThread;
rcvrthread-Init();
text-setUpdateCallback( new UpdateTextCallback(rcvrthread));
osg::ref_ptrosg::Geode geode = new osg::Geode;
geode-addDrawable( text.get() );
geode-getOrCreateStateSet()-setMode( GL_LIGHTING, osg::StateAttribute::OFF );
osgViewer::Viewer viewer;
viewer.setSceneData( geode.get() );
viewer.setUpViewInWindow( 50, 50, 640, 480 );
//status = rcvrthread-setProcessorAffinity(0);
//printf(setProcessorAffinity status: %d\n, status);
status = rcvrthread-setSchedulePolicy(OpenThreads::Thread::THREAD_SCHEDULE_ROUND_ROBIN);
printf(setSchedulePolicy status: %d\n, status);
if(!status)
printf(getSchedulePolicy: %d\n,rcvrthread-getSchedulePolicy());
status = rcvrthread-setSchedulePriority(OpenThreads::Thread::THREAD_PRIORITY_HIGH);
printf(setSchedulePriority status: %d\n, status);
if(!status)
printf(getSchedulePriority: %d\n,rcvrthread-getSchedulePriority());
rcvrthread-startThread();
viewer.run();
rcvrthread-cancel();
return 0;
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
