MISRA C:2023 Dir 5.1
Description
This checker is deactivated in a default Polyspace® as You Code analysis. See Checkers Deactivated in Polyspace as You Code Analysis (Polyspace Access).
Directive Definition
There shall be no data races between threads1 .
Rationale
A data race occurs when all of these conditions are true:
- Two actions on different threads attempt to read or modify the same memory location. 
- At least one of the actions is nonatomic. 
- The order of these operations is not fixed. 
In this code, the variable data is modified by the
            functions foo() and bar(), which are on separate
            threads. The order of execution for these threads is not specified and none of the
            actions is atomic. Both threads can attempt to modify data at the
            same time, resulting in a data race. Such a data race results in undefined
            behavior.
int64_t data = 0;
void foo() { /* thread 1*/
	while(1) {
		data = -1;
	}
}
void bar() { /* thread 2 */
	while(1) {
		data = 10;
	}
}data depends on the order of execution
            of the threads. Because data is a 64-bit integer, the write
            operations might be implemented as two different 32-bit load instructions by your
            compiler. In that case, it is possible that the writing of data by
               foo() is interrupted by bar() after the first
            32-bit load operation. As a result, the two 32-bit halves of data can
            be written by different threads, causing an unexpected value for
            data.Data races can cause unexpected and erratic behavior and memory corruption, resulting in bugs that are difficult to diagnose. To avoid data races, take steps to explicitly synchronize access to objects that are shared between threads. For instance:
- Declare shared objects as atomic. 
- Use mutex objects to synchronize threads that share objects. 
Polyspace Implementation
Polyspace reports violations of this directive when either of these conditions is met:
- Multiple tasks perform unprotected operations on a shared variable. This directive is not violated if both tasks perform read-only or atomic operations. 
- Multiple tasks perform unprotected calls to certain standard library functions. Unprotected calls to functions such as - strerror(),- setlocale(), or- getenv()can cause violations of this directive. For the list of functions that can cause a violation of this directive, see CON33-C: Avoid race conditions when using library functions.
Polyspace reports one violation for each shared variable with conflicting operations.
A task is a function that you specify as an entry point using the option Tasks (-entry-points). If you enable this directive without specifying
            tasks, Polyspace does not report any violations of this directive. 
To resolve violations of this directive, synchronize the threads in your code. Polyspace automatically recognizes the C11 concurrency library. See Auto-Detection of Thread Creation and Critical Section in Polyspace.
Troubleshooting
If you expect a rule violation but do not see it, refer to Diagnose Why Coding Standard Violations Do Not Appear as Expected.
Examples
Check Information
| Group: Concurrency Considerations | 
| Category: Required | 
| AGC Category: Required | 
Version History
Introduced in R2024b
1 All MISRA coding rules and directives are © Copyright The MISRA Consortium Limited 2021.
The MISRA coding standards referenced in the Polyspace Bug Finder™ documentation are from the following MISRA standards:
- MISRA C:2004 
- MISRA C:2012 
- MISRA C:2023 
- MISRA C++:2008 
- MISRA C++:2023 
MISRA and MISRA C are registered trademarks of The MISRA Consortium Limited 2021.