Re: Thread Scheduling question

Andy Ross

Your understanding is correct.  If a higher priority thread is available to run, then a preemptible thread will yield to that thread at every scheduling point.

I'm not quite sure what you are trying to mitigate, exactly.  This is the desired behavior.  You WANT your two custom threads to run instead of  your main thread, that's why they're higher priority.  I think you might want to revisit the priority design in your app, basically.  The priorities you've assigned to your threads don't reflect what you want them to do.

If you just need the custom threads to get out of the way at startup, why not just have them sleep a bit, or (much better) block on a semaphore or whatever waiting for main to signal them to begin.  Or you can change priorities at runtime -- have main start at a very high priority but then lower itself, for example.  Or launch the threads dynamically via k_thread_create() at runtime once you know it's safe for them to run...


On 5/10/2020 9:24 PM, Raj Gundi wrote:



This is a question related to thread scheduling. Imagine you have 2 custom threads in addition to the “main thread”. The custom threads are created static (K_THREAD_DEFINE) and are cooperative threads (let’s say the priority is -5) whereas the main thread is preemptive (priority 0). Now, as soon as the main thread is handed control (via switch_to_main_thread), it is possible the scheduler gets triggered and one of the cooperative threads gets scheduled. This may be undesirable since main thread may need to get some stuff done before the cooperative threads take over.


Is my reading of the above situation correct? If yes, I would like to see how this can be mitigated. One easy thing is to make main thread also cooperative (say, a priority of -6). The other is to lock the scheduler as soon as the main thread is entered and unlock only after the relevant stuff is addressed. Please let me know your views.




Join to automatically receive all group messages.