1
votes

I am trying to achieve the following:

Force the newly created thread to start running, immediately after pthread_create(). No real-time scheduling is being used.

From the pthread_create() man page:

Unless real-time scheduling policies are being employed, after a call to pthread_create(), it is indeterminate which thread—the caller or the new thread—will next execute.

Which of course makes sense. Thus, I thought by using pthread_yield() I would force the newly created thread to take over and as a result start. But this is not the case.

I could only achieve the desired result by sleeping after the pthread_create(). But I don't want to rely on this solution atm.

  1. Why can't I achieve my goal with pthread_yield()?
  2. Is there some other way than using sleep?
  3. The creation of new threads is handled the same way as task-switching, i.e. follows the scheduling policy? For example, in RT (preemptive) scheduling, if the newly created thread has a higher priority, will it immediately preempt the current thread?

Related post:

Thanks!

1
Use a condition and block after pthread_create() until the new thread signals the creator thread.Iharob Al Asimi
^^ should be an answer - it's an obvious and correct solution :)Martin James
Which thread in your code is calling pthread_yield()? pthread_yield() notifies the operating system that your thread is done working, and that it can switch execution to another thread.terence hill
@iharab yes that could be another solution. thx! But I am also trying to understand why the pthread_yield() approach is not working for me. @terence the thread that is calling pthread_create() is also calling pthread_yield().Tanasis
You may try to set the affinity and run your process on a specific core to see if pthread_yield() works, see for example here xmodulo.com/run-program-process-specific-cpu-cores-linux.htmlterence hill

1 Answers

0
votes

If you are on a multi-core system, then it is possible that your new thread is scheduled on a core different from the thread that created it. Calling pthread_yield() may not have the desired effect, since it may only affect scheduling on the core of the caller, and not any other core. The effect is usually placing the thread at the end of runnable queue. (It is also noteworthy that pthread_yield() is not a standard system call, so there is no standard reference regarding its intended behavior.)

Calling sleep() may yield a different result if the sleep time is non-zero. The thread is actually placed in a timer wake-up queue, and must be moved back to the runnable queue after the timer expires. This will make it more likely that a new thread on a different core will run before the creating thread wakes back up.

If a new thread has a higher priority than the thread that created it, it will preempt the creating thread.

As recommended in the comments, predictable behavior can be achieved by making the creating thread conditionally wait on a signal from the newly created thread.