richard_damon wrote on Saturday, May 14, 2011:
The idea is that FreeRTOS assumes that the actually increment will be atomic.
Even if not, vTaskSuspendAll is only called at task level (it doesn’t have FromISR) so no interrupt will affect the variable itself. If the increment is not atomic, then it turns out that it doesn’t cause problems in this case. If the interrupt occurs after the write of the new value, it will see the new value, if it occurs before, if the old number wasn’t zero, no task switch will occur, and since the interrupt doesn’t change the value it will return with out task switching (since the number isn’t zero) or changing the value. If the number was zero before, and thus seen as zero by the interrupt, a task switch might occur, but if it dose, the value now in uxSchedulerSuspended when the task gets switched back in is by definition 0, the same as before, so no harm in the non-atomic access interrupt by a task switch.