Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Cellular: Fix queue scheduling for bare metal #11859
Cellular event queue was not dispatched at all in case of bare metal build. This commit fixes the problem by chaining cellular queue with shared event queue.
Summary of change (What the change is for and why)
Documentation (Details of any document updates required)
Pull request type (required)
Test results (required)
Release Notes (required for feature/major PRs)
Summary of changes
Impact of changes
Migration actions required
This makes me nervous that you're going to cause large scheduling delays on the shared event queue (which has a guideline of <~100ms event duration) while waiting for an AT command response. Wasn't that the reason for having a separate event queue thread in the RTOS build in the first place?
Still, large scheduling delays are better than nothing working at all. And I suspect you may have occasionally ended up blocking the shared event queue waiting for an AT mutex anyway even in the RTOS setup.
We have some changes queued to backport (uhm it sounds easier than it will be) to introduce standard/high priority levels for the bare metal queue past Mbed 6. That should allow us to make sure higher priority work won't be blocked, would it mitigate this issue?
Not if the events do "send AT command, block waiting for response", as I think they do.
Within-queue priority levels don't really help that much (in general), because the responsiveness is determined by the longest-running event on a queue.
You can't pre-emptively stop a slow low-priority event from running when someone queues a high-priority one.
Priority levels can be useful, but only if both high and low priority events have similar execution time. Eg in Nanostack we did the work to have long-running crypto (on slow 16-bit platforms) break itself up into fraction-of-a-second units, and schedule that repeatedly at low priority.