Is ulTaskNotifyTake() Non-Deterministic?

ulTaskNotifyTake() calls prvAddCurrentTaskToDelayedList() within a critical section, which in turn can call vListInsert() if xTicksToWait is not equal to portMAX_DELAY. vListInsert() walks pxDelayedTaskList or pxOverflowDelayedTaskList to insert a list item in item value order. Does this mean ulTaskNotifyTake() is non-deterministic? Is maintaining determinism also the reason behind the following design decisions: * vTaskDelay() calling prvAddCurrentTaskToDelayedList() during scheduler suspension instead of a critical section * Queue send/receive functions calling vTaskPlaceOnEventList() during scheduler suspension instead of a critical section. Please let me know if my understanding of determinism incorrect. Thanks!

Is ulTaskNotifyTake() Non-Deterministic?

As a general rule FreeRTOS should not do anything non deterministic from an interrupt (which is why setting a bit in an event group is deferred to a task as you don’t know how many tasks that will unblock) or from a critical section (which is why scheduler locks are used). In this case it looks like that rule might have been breached – I will take a look to see how that can be managed. Thanks for taking the time to point this out.