Each task has its own private context, which includes the register values, a program counter, and a stack. However, all other data - g1obal, static, initialized, uninitialized, and everything else - is shared among all of the tasks in the system. The RTOS typically has its own private data structures, which are not available to any of the tasks. Since you can share data variables among tasks, it is easy to move data from one task to another: the two tasks need only have access to the same variables.
You can easily accomplish this by having the two tasks in the same module in which the variables are declared, or you can make the variables public in one of the tasks and declare them extern in the other.
Shared – Data Problems
If we have two tasks sharing the same data, it could happen that one of this tasks will read the half-changed data.
Reentrant functions are functions that can be called by more than one task and that will always work correctly even if the RTOS switches from one task to another in the middle of executing the function.
You apply three rules to decide if a function is reentrant:
1. A reentrant function may not use variables in a nonatomic way unless they are stored on the stack of the task that called. the function or are otherwise the private variables of that task.
2. A reentrant function may not call any other functions that are not themselves reentrant.
3. A reentrant function may not use the hardware in a nonatomic way.
To better understand reentrancy, and in particular rule l above, you must first understand where the C compiler will store variables. If you are a C language guru, you can skip the following discussion of where variables are stored in memory. If not, review your knowledge of C by examining the example and answering these questions: Which of the variables are stored on the stack and which in a fixed location in memory? What about the string literal “Where does this string go?” What about the data pointed to by vPointer? By parm_ptr?
static int static_int;
int initialized = 4;
char *string = “Where does this string go?”;
void function (int parm, int *parm_ptr)
static int static_local;
. . .
Here are the answers:
static_int - is in a fixed location in memory and is therefore shared by any task that happens to call function.
public_int - Ditto. The only differenice be-tween static_int and public_int is that functions in other C files can access public_int, but they cannot access static_int.(This means, of course, that it is even harder to be sure that this variable is not used by multiple tasks, since it might be used by any function in any module anywhere in the-system.)
initialized - The same. The initial value makes no difference to where the variable is stored.
string - The same.
“Where does this string go?" - Also the same.
vPointer - The pointer itself is in a fixed location in memory and is therefore a shared variable. If function uses or changes the data values pointed to by vPointer, then those data values are also shared among any tasks that happen to call function.
parm - is on the stack. If more than one task calls function, parm will be in a different location for each, because each task has its own stack. No matter how many tasks call function, the variable parm will not be a problem.
parm_ptr - is on the stack. Therefore, function can do anything to the value of parm_ptr without causing trouble. However, if function uses or changes the values of whatever is pointed to by parm_ptr, then we have to ask where that data is stored before we know whether we have a problem. We can’t answer that question just by looking at the code in lf we look at the code that calls function and can be sure that every task will pass a diderent value for parm_ptr, then all is well. If two tasks might pass in the same value for parm_ptr, then there might be trouble.
static_local - is in a fixed location in memory. The only difference between this and static_int is that static_int can be used by other functions in the same C file, whereas static_local can onlylbe used by function.
local - is on the stack.