tree f992ac4346850e7965a53c4c68e5e5bd84bdbb5c
parent 7ffc6a74655ec8a53fdc28fa1cccc74c1c747ecd
author Rahul Kar <118818625+kar-rahul-aws@users.noreply.github.com> 1697535318 +0530
committer GitHub <noreply@github.com> 1697535318 +0530
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJlLlVWCRBK7hj4Ov3rIwAAQ7wIAHS+m5sGQb2IcVwF34jUCZYq
 qWoxQRKYEY9XeSs7YdzheiAbbD9Ev8Gh5kKHfUF5DrOt9aZm/EEECvzy13KTIWHB
 2FGDuxUXzUDzBbB6ibkWYDHF9MFie5i/AQWqfVMTF5a93rel6JiDUtM2cQtqmF8P
 5ngQQ3rKORux1frmXGiVCn40SVf3NL2Vt75b7PZU6fcwxwfZeJj7jaGEXljGyKch
 Lz7lGkjbXdWLqesM1/X9RW2PkdVVWGtZ0Gh1HQ7JpHircUI0ug1/INBBpk8/QNLC
 QzzC7tS7DEWEoj9lJsnTTG/MW1c5Eb7lOOcQfDYgeNEzqcqwJGTxWBX2y9n+BvU=
 =8oUu
 -----END PGP SIGNATURE-----
 

Fix xTaskNotifyWait & ulTaskNotifyTake determinism. (#833)

This PR fixes the bug described in the following issue:
https://github.com/FreeRTOS/FreeRTOS-Kernel/issues/612.
This was originally contributed in the following 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:

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 <karver8@github.com>