Is ulTaskNotifyTake() Non-Deterministic?
Posted by
dazza0 on November 12, 2018
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?
Posted by
rtel on November 12, 2018
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.