You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was recently in a project hit by what I think is unintuitive behavior or at least a trap that I believe should be documented.
The RTIC_ASYNC_MAX_LOGICAL_PRIO value today gets calculated as one below the minimum priority of all hardware tasks. This works well when hardware tasks priorities are always strictly above those of software tasks, but it results in a subtle trap for buggy or long-running software tasks.
Consider the following tasks(the one that hit me):
Hardware USB interrupt handlers @ priority 1
Software peripheral management task @ priority 2
Software Communication processing task @ priority 3
UART tasks @ priority 6
Here, RTIC_ASYNC_MAX_LOGICAL_PRIO gets calculated as 0. This puts the timer hardware interrupt at priority 1 because of the clamping in set_monotonic_prio and therefore the async task at priority 3 now runs at a higher priority than the timer.
In my case, a bug in the priority 2 software task resulted in it running for extended durations with no await blocks. Of course this is a bug, but in this case it ended up breaking preemption not because it starved the higher priority tasks(whose priority was picked to be higher exactly because they are more important) but instead because the timer was placed at priority 1 which resulted in the timer no longer being able to make process and trigger delays within the priority 3 task. Of course this could also be triggered by a bug in a hardware task, like the USB handler, causing it to run forever.
This may be the intended situation, which is fine, but I think it would be good to document this particular aspect. Ideally I think it would be better to increase the priority of the timer task to be at least 1 above the highest software task. From my understanding of the monotonic API, there's really no way to interact monotonics except inside a software task, so to me it's a trap for new players that you can end up starving your software tasks for progress if a hardware task is placed at lower priority than the software tasks.
I can make a PR for whatever path forward is the correct one, but I'd like some input on what is considered correct for the project.
Best regards,
Lasse
The text was updated successfully, but these errors were encountered:
Hi,
I was recently in a project hit by what I think is unintuitive behavior or at least a trap that I believe should be documented.
The
RTIC_ASYNC_MAX_LOGICAL_PRIO
value today gets calculated as one below the minimum priority of all hardware tasks. This works well when hardware tasks priorities are always strictly above those of software tasks, but it results in a subtle trap for buggy or long-running software tasks.Consider the following tasks(the one that hit me):
Here,
RTIC_ASYNC_MAX_LOGICAL_PRIO
gets calculated as 0. This puts the timer hardware interrupt at priority 1 because of the clamping inset_monotonic_prio
and therefore the async task at priority 3 now runs at a higher priority than the timer.In my case, a bug in the priority 2 software task resulted in it running for extended durations with no
await
blocks. Of course this is a bug, but in this case it ended up breaking preemption not because it starved the higher priority tasks(whose priority was picked to be higher exactly because they are more important) but instead because the timer was placed at priority 1 which resulted in the timer no longer being able to make process and trigger delays within the priority 3 task. Of course this could also be triggered by a bug in a hardware task, like the USB handler, causing it to run forever.This may be the intended situation, which is fine, but I think it would be good to document this particular aspect. Ideally I think it would be better to increase the priority of the timer task to be at least 1 above the highest software task. From my understanding of the monotonic API, there's really no way to interact monotonics except inside a software task, so to me it's a trap for new players that you can end up starving your software tasks for progress if a hardware task is placed at lower priority than the software tasks.
I can make a PR for whatever path forward is the correct one, but I'd like some input on what is considered correct for the project.
Best regards,
Lasse
The text was updated successfully, but these errors were encountered: