Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Considerations around calculation of RTIC_ASYNC_MAX_LOGICAL_PRIO #1008

Open
dalegaard opened this issue Jan 7, 2025 · 0 comments
Open

Considerations around calculation of RTIC_ASYNC_MAX_LOGICAL_PRIO #1008

dalegaard opened this issue Jan 7, 2025 · 0 comments

Comments

@dalegaard
Copy link
Contributor

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):

  • 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant