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] [February 2010 Threads] portBASE_TYPE & critical sectionPosted 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 sectionPosted 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 sectionPosted 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.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|