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:
Exit critical section.
Interrupt - ISR calls xTaskNotifyFromISR which adds the task to the Ready list.
Suspend scheduler.
prvAddCurrentTaskToDelayedList moves the task to the delayed or suspended list.
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:
Suspend scheduler.
Exit critical section.
Interrupt - ISR calls xTaskNotifyFromISR which adds the task to the pendingReady list as the scheduler is suspended.
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.
Resume scheduler moves the task from pendingReady list to the Ready 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:
[x] I have tested my changes. No regression in existing tests.
[ ] I have modified and/or added unit-tests to cover the code changes in this Pull Request.
Description
Fixes the bug described in this issue: https://github.com/FreeRTOS/FreeRTOS-Kernel/issues/612. This was originally contributed in this PR: https://github.com/FreeRTOS/FreeRTOS-Kernel/pull/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:
xTaskNotifyFromISR
which adds the task to the Ready list.prvAddCurrentTaskToDelayedList
moves 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:
xTaskNotifyFromISR
which adds the task to the pendingReady list as the scheduler is suspended.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.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
https://github.com/FreeRTOS/FreeRTOS-Kernel/issues/612
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.