vTaskSuspendAll() Critical Section

tacadia wrote on Wednesday, May 11, 2011:

Hi all,

For this function:

void vTaskSuspendAll( void )
	/* A critical section is not required as the variable is of type
	portBASE_TYPE. */

This is generated as a multi-line assembly code and can be interrupted. I was just wondering, why in this case will we not need a critical section? Just because it is of portBASE_TYPE?

Thanks in advance. Cheers!

davedoors wrote on Thursday, May 12, 2011:

That is what is says, in the code that you have posted.

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.

tacadia wrote on Thursday, May 19, 2011:

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.

Warmest Regards :slight_smile: