Variables Set in Multiple Tasks
For example, you can have the report check for variables that are set in more than task. Such variable assignments can cause unforeseen and defective behavior in the tasks that use those variables if they are not protected by critical regions. The report supports five other specific scenarios. Alternatively, you can have the report list all usage of non-local variables, and review the use of each variable yourself. Consider the following code:
Critical region protection, through the use of semaphores or interrupt control functions (DisableInt and EnableInt in this example) provides protection against unplanned interference with global variable values by other tasks. For example, the value of globalB when it's read in subX is assured of being the value assigned to globalB earlier in subX, as subX is protected by the DisableInt in taskX. As a result, an interrupt by taskY can't change globalB during the calculation time that occurs between the set and read of globalB in subX.
In contrast, the set and subsequent read of globalA in taskX is not protected. If an interrupt by taskY occurs in between the set and read, the value of globalA will be modified, interfering with the planned behavior of taskX.
The Variables Set in Multiple Tasks report includes analysis about whether the variable assignments occur in critical regions, and this information is included in the display. You're also able to filter out protected variable usage. Here, both protected and unprotected sets of variables are displayed. The access status for a given usage indicated by a U(nprotected) or P(rotected). For protected accesses, the name of the critical region indicated; here, one critical region has been defined in the Critical Region Definitions dialog, and given the name int.
One of the alternative usage settings of the report is to identify variables that have been used (set and/or read) in at least on of the tasks. As the listing of protected usage is omitted, the results focus on variable usage outside of the critical region protection. These uses could merit individual review.
When both sets and reads are analyzed, the usage type information about the accesses is added to the report. The access type is indicated by an S(et) or R(ead). Additional variables, such as globalC, will be listed, if they are only set in one task, but read in another.
Aggregate variables consist of structs and unions in C/C++ plus classes in C++. This report, along with some of the following ones, has options to control how aggregate variables are reported. If you ask for a Container Summary in the reports, then any member of these aggregates contributes to the container variable summary. For example, if one member of a struct is assigned in one task and another member of this struct is assigned in another task, then the members are not showing up in the Variables Set in Multiple Tasks report but the containing struct variable will.
Arrays on the other hand are considered a single variable by these reports because in general it is not possible to distinguish which array component has been assigned, as the indices can be dynamic expressions.
As much as is feasible via static analysis, Imagix 4D tracks which objects are referenced by pointers. Pointers or reference parameters track their actual parameter variables and derive potential changes that way. Pointers set to an array and used to index through an array cause the array to be modified. Imagix 4D assumes "clean" pointer usage, i.e. pointers are set to a certain variable and operate just on that variable but don't use side effects to access independent variables which are allocated in neighboring memory areas.