C++ has threading and shared access to variables which have the vulnerabilities described in ISO/IEC TR 24772-1:2019 clause 6.61.1. C++ provides features such as atomic (type template) to guarantee the internal consistency of the data and to prevent corruption of data due to potentially interleaved updates to data elements.
What about concurrent data access between tasks?
Programmers should be aware that conversions or manipulations of data items are not always atomic, such as the conversion of an object as part of a computation
Need the C++ definition of atomic (indivisible access and memory ordering)
and volatile.
The C++ atomic capability can be applied to any basic data type equivalent to char, short, int, long, and long long. When the C++ std::atomic facilities are used, the language guarantees that simultaneous updates and reads to an atomic element will be well-behaved. Atomic does not guarantee the order in which competing reads and/or updates will occur. In order to manage order of access, synchronized locks are required. In order to use the atomic capabilities, each variable must be declared to be of one of the std::atomic types, and the member functions used to compare, load, store or exchange values in an atomic variable.
We also need to move the notion of creating SHARED POINTERS FROM 6.13 TO HERE.
A volatile qualifier on a variable is used to indicate that updates to the variable may happen at any time and outside of program control, hence two subsequent reads on such a variable may return different results.
Programmers should be aware that even simple data accesses on modern architectures can involve instruction reordering, cache issues, and data alignment issues, hence the acquisition time and order are highly nondeterministic, especially when being accessed by concurrent threads. Any data structure that can be shared between threads should be shown to be accessed by at most one thread at a time or should be protected by synchronization mechanisms such as locks (see Lock Protocol Errors [CGM]) or atomicity.
Most concurrent programming algorithms require some level of synchronization between threads or tasks when exchanging information, synchronization that “atomic” does not provide. Mechanisms such as monitors, mailboxes, or mutexes (lock with a queue), futures, condition variables, and locks control scheduling of threads or tasks to control order-of-access and to enforce higher levels of cooperation between schedulable entities.
Atomic tied to memory orders.
Mutexes provide mutual exclusion and guaranteed visibility (consistency) of the shared data.
Mutex is a lock-and-release that is usually hidden.
Encapsulate mutexes and data
Thread-level storage (official term thread_local) has lifetime of the thread. Can exist at local scope or global scope.
For massively parallel concurrency – concurrent access mechanisms not applicable.
No resource management
Exception and exception handling (has some impact on threading)
Memory management issues more complex under concurrency
Volatile should be used for signal handlers to prevent the optimization of replicated accesses to volatile memory. (other) and does not guarantee that the object value will be available to other threads.
Controlling access to shared data (protected or including
Use of volatile (keyword type qualifier) for signal handlers (communicating with hardware?). Prefer volatile for communicating with hardware?
For signal handling, volatile sig_atomic_t or atomic variables can be used to prevent this vulnerability.
To avoid the vulnerability or mitigate its ill effects, C++ software developers can:
Follow the avoidance mechanisms of ISO/IEC 24772-1 clause 6.62.5.
Use mutexes and condition variables (convar) in preference to atomic variables to protect data from simultaneous access.
Use volatile only for synchronizing abstract machine state from memory.
Avoid the use of volatile for synchronizing access to shared memory between threads (which needs mutex, condvar, or atomics)
See C++ Core guidelines CP.8, CP.200,Avoid relaxed atomic operations whenever possible. Prefer the sequentially consistent std::memory_order_seq_cst instead .
Use mutexes appropriately to protect accesses to non-atomic shared objects.
Use volatile sig_atomic_t to protect data shared with signal handlers in a single-threaded environment.
Pass all thread function arguments by value, or ensure their lifetime outlasts the running thread. In the latter case proper synchronization is required.