Topics

Thread Scheduling question


Raj Gundi
 

Hi,

 

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.

 

Regards,

Raj


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...

Andy

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

Hi,

 

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.

 

Regards,

Raj


Raj Gundi
 

This will help, Andy. Thanks for your inputs!

 

Regards,

Raj

 

From: Ross, Andrew J <andrew.j.ross@...>
Sent: 11 May 2020 10:53
To: Gundi, Rajavardhan <rajavardhan.gundi@...>; devel@...
Subject: Re: [Zephyr-devel] Thread Scheduling question

 

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...

Andy

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

Hi,

 

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.

 

Regards,

Raj


Peter A. Bigot
 

> 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 the mitigation is of Zephyr's default behavior: that the main thread is preemptible by default.  I've also run into this where starting a repeating timer with no initial delay in main caused a work item to be submitted (from interrupt) and started (from system work thread, which is default cooperative) before I'd finished configuring the work item back in main.

Not that it's wrong, but it's unexpected to have main be preemptible, and since every thread declared in the samples and drivers is cooperative people just starting with threads are likely to make this "mistake".

Peter