CertC++-CON52¶
Prevent data races when accessing bit-fields from multiple threads
Required inputs: IR
When accessing a bit-field, a thread may inadvertently access a separate bit-field in adjacent memory. This is because compilers are required to store multiple adjacent bit-fields in one storage unit whenever they fit. Consequently, data races may exist not just on a bit-field accessed by multiple threads but also on other bit-fields sharing the same byte or word. The problem is difficult to diagnose because it may not be obvious that the same memory location is being modified by multiple threads.
One approach for preventing data races in concurrent programming is to use a mutex. When properly observed by all threads, a mutex can provide safe and secure access to a shared object. However, mutexes provide no guarantees with regard to other objects that might be accessed when the mutex is not controlled by the accessing thread. Unfortunately, there is no portable way to determine which adjacent bit-fields may be stored along with the desired bit-field.
Another approach is to insert a non-bit-field member between any two bit-fields to ensure that each bit-field is the only one accessed within its storage unit. This technique effectively guarantees that no two bit-fields are accessed simultaneously.
Noncompliant Code Example (bit-field)
Adjacent bit-fields may be stored in a single memory location. Consequently, modifying adjacent bit-fields in different threads is undefined behavior, as shown in this noncompliant code example.
struct MultiThreadedFlags {
unsigned int flag1 : 2;
unsigned int flag2 : 2;
};
MultiThreadedFlags flags;
void thread1() {
flags.flag1 = 1;
}
void thread2() {
flags.flag2 = 2;
}
For example, the following instruction sequence is possible.
Thread 1: register 0 = flags Thread 1: register 0 &= ~mask(flag1) Thread 2: register 0 = flags Thread 2: register 0 &= ~mask(flag2) Thread 1: register 0 |= 1 << shift(flag1) Thread 1: flags = register 0 Thread 2: register 0 |= 2 << shift(flag2) Thread 2: flags = register 0
Compliant Solution (bit-field, C++11 and later, mutex)
This compliant solution protects all accesses of the flags with a mutex, thereby preventing any data races.
#include <mutex>
struct MultiThreadedFlags {
unsigned int flag1 : 2;
unsigned int flag2 : 2;
};
struct MtfMutex {
MultiThreadedFlags s;
std::mutex mutex;
};
MtfMutex flags;
void thread1() {
std::lock_guard<std::mutex> lk(flags.mutex);
flags.s.flag1 = 1;
}
void thread2() {
std::lock_guard<std::mutex> lk(flags.mutex);
flags.s.flag2 = 2;
}
Compliant Solution (C++11)
In this compliant solution, two threads simultaneously modify two distinct non-bit-field members of a structure. Because the members occupy different bytes in memory, no concurrency protection is required.
struct MultiThreadedFlags {
unsigned char flag1;
unsigned char flag2;
};
MultiThreadedFlags flags;
void thread1() {
flags.flag1 = 1;
}
void thread2() {
flags.flag2 = 2;
}
Unlike earlier versions of the standard, C++11 and later explicitly define a memory location and provide the following note in [intro.memory] paragraph 4 [ ISO/IEC 14882-2014]:
[Note: Thus a bit-field and an adjacent non-bit-field are in separate memory locations, and therefore can be concurrently updated by two threads of execution without interference. The same applies to two bit-fields, if one is declared inside a nested struct declaration and the other is not, or if the two are separated by a zero-length bit-field declaration, or if they are separated by a non-bit-field declaration. It is not safe to concurrently update two bit-fields in the same struct if all fields between them are also bit-fields of non-zero width. - end note]
It is almost certain that
flag1 and
flag2 are stored in the same word. Using a compiler that
conforms to earlier versions of the standard, if both assignments occur on a
thread-scheduling interleaving that ends with both stores occurring after one
another, it is possible that only one of the flags will be set as intended, and
the other flag will contain its previous value because both members are
represented by the same word, which is the smallest unit the processor can work
on. Before the changes made to the C++ Standard for C++11, there were no
guarantees that these flags could be modified concurrently.
Risk Assessment
Although the race window is narrow, an assignment or an expression can evaluate improperly because of misinterpreted data resulting in a corrupted running state or unintended information disclosure.
| Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
| CON52-CPP | Medium | Probable | Medium | P8 | L2 |
Related Guidelines
| SEI CERT C Coding Standard | CON32-C. Prevent data races when accessing bit-fields from multiple threads |
Bibliography
| [ ISO/IEC 14882-2014] | Subclause 1.7, "The C++ memory model" |
Possible Messages
Key |
Text |
Severity |
Disabled |
|---|---|---|---|
data-race-on-bitfields |
Prevent data races when accessing bit-fields from multiple threads. |
None |
False |
Options¶
This rule shares the following common options: exclude_in_macros, exclude_messages_in_system_headers, excludes, extend_exclude_to_macro_invocations, includes, justification_checker, languages, post_processing, provider, report_at, severity
The following places define options that affect this rule: Stylechecks, Analysis-GlobalOptions
access_kinds¶
access_kinds : set[bauhaus.ir.LIR_Class_Name] = {'Reading_Operand_Interface', 'Writing_Operand_Interface'}
Reading_Operand_Interface,
Writing_Operand_Interface, Address_Operand_Interface).
allow_c11_atomics¶
allow_c11_atomics : bool = True
allow_volatile_sig_atomic_t¶
allow_volatile_sig_atomic_t : bool = False
volatile sig_atomic_t.
debug_output¶
debug_output : bool = False
enter_critical_functions¶
enter_critical_functions
Set of function names to enter a critical region.Type: set[bauhaus.analysis.config.QualifiedName]
Default:
{'EnterCriticalSection', 'mtx_lock', 'pthread_mutex_lock', 'std::_Mutex_base::lock', 'std::mutex::lock'}
enter_critical_macros¶
enter_critical_macros : set[bauhaus.analysis.config.MacroName] = set()
excluded_routines¶
excluded_routines : set[bauhaus.analysis.config.QualifiedName] = set()
excluded_subgraphs¶
excluded_subgraphs : set[bauhaus.analysis.config.QualifiedName] = set()
exit_critical_functions¶
exit_critical_functions
Set of function names to exit a critical region.Type: set[bauhaus.analysis.config.QualifiedName]
Default:
{'ExitCriticalSection', 'mtx_unlock', 'pthread_mutex_unlock', 'std::_Mutex_base::unlock', 'std::mutex::unlock'}
exit_critical_macros¶
exit_critical_macros : set[bauhaus.analysis.config.MacroName] = set()
inspect_pointers¶
inspect_pointers : bool = False
nested_critical_regions¶
nested_critical_regions : bool = True
output_safe_accesses¶
output_safe_accesses : bool = False
partitions¶
partitions : dict[str, dict[str, typing.Any]] = {}
entries: list of entry functions or this task/isrfunctions_passed_to: name of thread creation function. Any function designated by a pointer passed to that function will be considered an entry function.vectors: list of global variable names with function pointers to entry functions or this task/ISRguarded: boolean property. Set toTrueif this task is nonpreemptive and cannot be interrupted by interrupt handlers. Set toFalseor omit otherwise (default).
__interrupts__ will automatically contain
all interrupt handlers recorded as Additional_Entries in IR (see
compiler toolchain's advanced.main_entries configuration) in addition
to any entries specified in its dict.
report_cfg_based_critical_region_issues¶
report_cfg_based_critical_region_issues : bool = False
show_identical_access¶
show_identical_access : bool = True
show_object_number¶
show_object_number : bool = False
strict_priorities¶
strict_priorities : bool = False
treat_types_as_atomic¶
treat_types_as_atomic : set[typing.Pattern[str] | typing.Tuple[typing.Optional[int], typing.Optional[int], typing.Optional[typing.Pattern[str]]]] = set()