FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [May 2011 Threads] vTaskSuspendAll() Critical SectionPosted by Ivan on 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. */ ++uxSchedulerSuspended; } 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!
RE: vTaskSuspendAll() Critical SectionPosted by Dave on May 12, 2011 That is what is says, in the code that you have posted.
RE: vTaskSuspendAll() Critical SectionPosted by Richard Damon on 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.
RE: vTaskSuspendAll() Critical SectionPosted by Ivan on 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 :)
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|