Is ulTaskNotifyTake() Non-Deterministic?

Kernel
#1

dazza0 wrote on Monday, 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!

#2

rtel wrote on Monday, 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.

#3

@rtel, did you have any findings w.r.t. the original question?

Thanks,
Bin