On Fri, Oct 8, 2021 at 1:01 AM Alexander Carôt via Boost-users <boost-users@lists.boost.org> wrote:

> You must wait until the thread is actually started before you can set
> its priority.  Usually the best place to set it is from the thread's
> method itself.

Is this related to any platform or just WIN32 as you mention above ? In other words: Is my approach of setting the priority fine for OSX and Linux or should it be changed as well ?

You can't set traits on a thread that doesn't exist, regardless of platform, 

Posix APIs offer a way to set up attributes to be applied to a new thread at thread creation. At first, that's what I thought you were doing, but when I look at your code, I'm not sure what you're doing.  I don't see a definitely for `attrs` anywhere in the snippet, but I'm guessing that `attrs.native_handle()` is supposed to return a `pthread_t` ?  If so, then your call to pthread_attr_setschedpolicy() doesn't match its prototype--which takes a pthread_attr_t* as first arg.
 
> >      #elif defined(BOOST_THREAD_PLATFORM_PTHREAD)
> >          pthread_attr_setschedpolicy(attrs.native_handle(), SCHED_FIFO);
> >      #endif
> >      tracerouteThread = boost::thread(
> >          attrs, boost::bind(&test::performTraceroute, this));
>
> For Win32, you can't call SetThreadPriority like that -- at best, that's
> doing nothing, at worst, you're changing the priority of some random
> thread but never the one you intend.  (The attrs.native_handle is not a
> thread handle.)
>
> You must wait until the thread is actually started before you can set
> its priority.  Usually the best place to set it is from the thread's
> method itself.

On linux, sometimes the only way you can actually set priority on a thread is to set the attributes prior to thread creation and create the thread that way.  This would be the case if you're using something like `isolcpus` on your kernel, and the thread doing the creating is running on one of the isolcpus, because the default behavior is for the new thread to inherit properties of the parent, and with isolcpus the scheduler doesn't arbitrate the designated cpus, so the new thread will never get a chance to run and change its attributes.

-- 
Chris Cleeland