- Take and give a recursive mutex.
Probably a bit heavy for linked list, assuming the linked list is fast.
- vTaskSuspendAll and xTaskResumeAll. The documentation doesn’s state
whether this is recursive, but I can wrap it to make it so if necessary.
Yes, this is recursive. Suspending the scheduler is fast and
deterministic, resuming the scheduler can take longer because, if tasks
were moved out of the blocked state while the scheduler was suspended
then they will have been placed into a pending list, and moved from the
pending list into their respective ready lists when the scheduler is
resumed. So this method is fast in most cases, but could be slightly
slower occasionally if tasks are unblocked while the scheduler is
suspended. Note that suspending the scheduler does NOT mask interrupts,
they keep executing, so this does not protect the linked list if
interrupts also access the list. It also means that only interrupts can
ever move tasks out of the Blocked state (and into the above mentioned
pending list) while the scheduler is suspended. If non of your
interrupts can do that then this is a good method.
- taskENTERCRITICAL and task EXITCRITICAL.
This is the fastest method – very fast to enter a critical section and
very fast to exit, so is the ideal method if the section being protected
is very short. It does however mask interrupts up to
- cpuirqsave and cpuirqrestore from the ARM Cortex library.
Would be very wary about using that method if it modifies the BASEPRI
register as BASEPRI is under the control of FreeRTOS. If it only
updates the global interrupt enable bit then that should be ok but keep
in mind it will mask all your interrupts, whereas FreeRTOS critical
sections only mask some.
Given all the above, I think your statements are basically correct.