Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

portBASE_TYPE & critical section

Posted by c77er on February 19, 2010
I was comparing the latest FreeROTS version (6.0.2) and an earlier one (version 4.4.0). Here's what puzzles me:

In file tasks.c, function vTaskSuspendAll(), the statement "++uxSchedulerSuspended;" was protected by a critical section in version 4.4.0. While in 6.0.2, it is not, and the comment in 6.0.2 gave the rationale: "A critical section is not required as the variable is of type portBASE_TYPE."

I'm confused - even if the variable is a base type, the "++" essentially is still a load-increment-store. If the current process got interrupted right between "load" and "increment", and preempted by another process which also calls this same function, the race condition is still there and would cause an error.

Am I missing something here?

Thanks in advance.

RE: portBASE_TYPE & critical section

Posted by Ricky on February 19, 2010
The key is when the variable gets written. If it's written in one operation then all is well.

Consider the following scenario:

Task 1 calls vTaskSuspendAll and grabs uxSchedulerSuspended and increments it but doesn't get a chance to store it because an interrupt occurs. Task 2 gains control and calls the same function which halts the scheduler. When task 2 finishes, uxSchedulerSuspended gets decremented back to its original value. Task 1 regains control and stores the incremented value to suspend the scheduler. When Task 1 finishes, uxSchedulerSuspended gets decremented and the scheduler starts again.

If it took two writes to store uxSchedulerSuspended, then there would be a danger since the first write would corrupt the value until the second write was done. An interrupt between the writes would cause any task using that variable to use a corrupted value.

RE: portBASE_TYPE & critical section

Posted by Richard Damon on February 20, 2010
Another way to take a look at this, and it is based on the essential nature of the variable, is to look at what happens with different values of the variable.

If it is non-zero at the start, then if an interrupt comes between the read and the write, so no problems can occur.

If it is zero at the start, then an interrupt might cause a task switch, but if it does, when it get back to this task, the variable will be zero again.

The key feature is there is only a single value of this variable that allows a task change, so there is no danger of it change behind the operations back.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS