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.
Thanks loads for the clear explanation. I came to realization that FreeRTOS had wanted for the compiler to compile into atomic machine code that reads, updates and write at one go. Subsequently, I ran through a couple of test cases like you mentioned and found that they were still safe.
Once again, thank you very much for helping me understand.