Fix xTaskNotifyWait & ulTaskNotifyTake determinism. #833
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
htibosch
reviewed
Oct 13, 2023
Signed-off-by: Gaurav Aggarwal <[email protected]>
aggarg
approved these changes
Oct 16, 2023
2 tasks
|
Kudos, SonarCloud Quality Gate passed!
|
chinglee-iot
approved these changes
Oct 17, 2023
This was referenced Oct 17, 2023
n9wxu
pushed a commit
to n9wxu/FreeRTOS-Kernel
that referenced
this pull request
Oct 26, 2023
This PR fixes the bug described in the following issue: FreeRTOS#612. This was originally contributed in the following PR: FreeRTOS#625. The implementation suspends the scheduler before exiting the critical section (i.e. before enabling interrupts). If we do not do so, a notification sent from an ISR, which happens after exiting the critical section and before suspending the scheduler, will get lost. The sequence of events will be: 1. Exit critical section. 2. Interrupt - ISR calls xTaskNotifyFromISR which adds the task to the Ready list. 3. Suspend scheduler. 4. prvAddCurrentTaskToDelayedList moves the task to the delayed or suspended list. 5. Resume scheduler does not touch the task (because it is not on the pendingReady list), effectively losing the notification from the ISR. The same does not happen when we suspend the scheduler before exiting the critical section. The sequence of events in this case will be: 1. Suspend scheduler. 2. Exit critical section. 3. Interrupt - ISR calls xTaskNotifyFromISR which adds the task to the pendingReady list as the scheduler is suspended. 4. prvAddCurrentTaskToDelayedList adds the task to delayed or suspended list. Note that this operation does not nullify the add to pendingReady list done in the above step because a different list item, namely xEventListItem, is used for adding the task to the pendingReady list. In other words, the task still remains on the pendingReady list. 5. Resume scheduler moves the task from pendingReady list to the Ready list. ------------ Co-authored-by: Jacob Carver <[email protected]>
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Fixes the bug described in this issue: #612. This was originally contributed in this PR: #625.
The implementation suspends the scheduler before exiting the critical section (i.e. before enabling interrupts). If we do not do so, a notification sent from an ISR, which happens after exiting the critical section and before suspending the scheduler, will get lost. The sequence of events will be:
xTaskNotifyFromISRwhich adds the task to the Ready list.prvAddCurrentTaskToDelayedListmoves the task to the delayed or suspended list.The same does not happen when we suspend the scheduler before exiting the critical section. The sequence of events in this
case will be:
xTaskNotifyFromISRwhich adds the task to the pendingReady list as the scheduler is suspended.prvAddCurrentTaskToDelayedListadds the task to delayed or suspended list. Note that this operation does not nullifythe add to pendingReady list done in the above step because a different list item, namely xEventListItem, is used for
adding the task to the pendingReady list. In other words, the task still remains on the pendingReady list.
Test Steps
Tested by adding a dummy loop in the implementation to cause a button press interrupt at the desired point and ensured that the notification is not lost.
Checklist:
Related Issue
#612
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.