RDKBWIFI-348: Fix Race condition between timer tasks and scheduler execution#908
Conversation
github-actions
bot
added
the
community contribution
…ecution
Reason for change: The existing timeout calculation is based on current time scheduler start.
If the scheduler timeout and timer task interval is same, small micro seconds difference in scheduler start make the timer task to skip the execution and need to wait till the next iteration.
Fixed the issue a) by modifying the timeout calculation based on last timeout instead of current time. And
b) updated timeout while adding a new timer task with start_immediately as false.
Test Procedure: Ensure the timer task run in configured intervals and no regressions.
Risks: Medium
Priority: P1
Signed-off-by: Rakhil P E <rakhilpe001@gmail.com>
rakhilpe
force-pushed
the
timer_schedule_fix
branch
from
594e464 to
1805d40
Compare
There was a problem hiding this comment.
Pull request overview
This pull request fixes a race condition in the timer task scheduler where small microsecond timing differences could cause timer tasks to skip executions. The fix changes the timeout calculation logic from being based on the current time to being based on the previous timeout, which maintains fixed intervals and prevents timing drift.
Changes:
- Modified timeout calculation in
scheduler_calculate_timeoutto use previous timeout instead of current time for determining next execution time - Added proper timeout initialization for timer tasks created with
start_immediately=falseto ensure they don't execute immediately - These changes ensure timer tasks maintain consistent execution intervals even with minor timing variations in scheduler execution
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| } | ||
| tt->execute = timespecisset(&tt->timeout); | ||
| timespecadd(&t_now, &(tt->interval), &(tt->timeout)); | ||
| timespecadd(&(tt->timeout), &(tt->interval), &(tt->timeout)); |
There was a problem hiding this comment.
The timeout calculation has been changed from current-time-based to previous-timeout-based to maintain fixed intervals and prevent timing drift. This ensures timer tasks execute consistently even with small microsecond variations in scheduler timing.
However, be aware that if a timer task execution is significantly delayed (e.g., system suspension, heavy load, or long-running callbacks), the task may execute multiple times in quick succession to catch up to the intended schedule. Consider whether this catch-up behavior is appropriate for all use cases, and document it if it's intentional.
The same consideration applies to the high-priority task timeout calculation on line 501.
3 participants
RDKBWIFI-348: Fix Race condition between timer tasks and scheduler execution
Reason for change: The existing timeout calculation is based on current time scheduler start. If the scheduler timeout and timer task interval is same, small micro seconds difference in scheduler start make the timer task to skip the execution and need to wait till the next iteration.
Fixed the issue -
a) by modifying the timeout calculation based on last timeout instead of current time. And
b) updated timeout while adding a new timer task with start_immediately as false.
Test Procedure: Ensure the timer task run in configured intervals and no regressions. Risks: Medium
Priority: P1