Are C/C++ fundamental types, like int, double, etc., atomic, e.g. threadsafe?
Are they free from data races; that is, if one thread writes to an object of such a type while another thread reads from it, is the behavior well-defined?
If not, does it depend on the compiler or something else?
No, fundamental data types (e.g., int, double) are not atomic, see std::atomic.
Instead you can use std::atomic<int> or std::atomic<double>.
Note: std::atomic was introduced with C++11 and my understanding is that prior to C++11, the C++ standard didn't recognize the existence of multithreading at all.
As pointed out by @Josh, std::atomic_flag is an atomic boolean type. It is guaranteed to be lock-free, unlike the std::atomic specializations.
The quoted documentation is from: http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4567.pdf. I'm pretty sure the standard is not free and therefore this isn't the final/official version.
- Two expression evaluations conflict if one of them modifies a memory location (1.7) and the other one reads or modifies the same memory location.
- The library defines a number of atomic operations (Clause 29) and operations on mutexes (Clause 30) that are specially identified as synchronization operations. These operations play a special role in making assignments in one thread visible to another. A synchronization operation on one or more memory locations is either a consume operation, an acquire operation, a release operation, or both an acquire and release operation. A synchronization operation without an associated memory location is a fence and can be either an acquire fence, a release fence, or both an acquire and release fence. In addition, there are relaxed atomic operations, which are not synchronization operations, and atomic read-modify-write operations, which have special characteristics.
- Two actions are potentially concurrent if
(23.1) — they are performed by different threads, or
(23.2) — they are unsequenced, and at least one is performed by a signal handler.
The execution of a program contains a data race if it contains two potentially concurrent conflicting actions, at least one of which is not atomic, and neither happens before the other, except for the special case for signal handlers described below. Any such data race results in undefined behavior.
- There shall be explicit specializations of the atomic template for the integral types ``char,
signed char,unsigned char,short,unsigned short,int,unsigned int,long,unsigned long,long long,unsigned long long,char16_t,char32_t,wchar_t, and any other types needed by the typedefs in the header<cstdint>. For each integral type integral, the specializationatomic<integral>provides additional atomic operations appropriate to integral types. There shall be a specializationatomic<bool>which provides the general atomic operations as specified in 29.6.1..
- There shall be pointer partial specializations of the atomic class template. These specializations shall have standard layout, trivial default constructors, and trivial destructors. They shall each support aggregate initialization syntax.
- Operations on an object of type atomic_flag shall be lock-free. [ Note: Hence the operations should also be address-free. No other type requires lock-free operations, so the atomic_flag type is the minimum hardware-implemented type needed to conform to this International standard. The remaining types can be emulated with atomic_flag, though with less than ideal properties. — end note ]
std::mutex then? (Playing devil's advocate here, it's just that that sentence needs a bit of love and some reference into the Standard.) –
Psalmist std::atomic which are free from data races. Only the Standard is the Voice of The One True ^W^W^W^W the reference here. –
Psalmist mutex, its companions, etc.); and notably, the primitive types are not amongst these, so they're not safe. –
Psalmist Since C is also (currently) mentioned in the question despite not being in the tags, the C Standard states:
5.1.2.3 Program execution
...
When the processing of the abstract machine is interrupted by receipt of a signal, the values of objects that are neither lock-free atomic objects nor of type
volatile sig_atomic_tare unspecified, as is the state of the floating-point environment. The value of any object modified by the handler that is neither a lock-free atomic object nor of typevolatile sig_atomic_tbecomes indeterminate when the handler exits, as does the state of the floating-point environment if it is modified by the handler and not restored to its original state.
and
5.1.2.4 Multi-threaded executions and data races
...
Two expression evaluations conflict if one of them modifies a memory location and the other one reads or modifies the same memory location.
[several pages of standards - some paragraphs explicitly addressing atomic types]
The execution of a program contains a data race if it contains two conflicting actions in different threads, at least one of which is not atomic, and neither happens before the other. Any such data race results in undefined behavior.
Note that values are "indeterminate" if a signal interrupts processing, and simultaneous access to types that are not explicitly atomic is undefined behavior.
_Atomic type qualifier and the <stdatomic.h> header... –
Ardin Atomic, as describing something with the property of an atom. The word atom originates from Latin atomus meaning "undivided".
Typically I think of an atomic operation (regardless of language) to have two qualities:
I.e. it is performed in an indivisible way, I believe this is what OP refers to as "threadsafe". In a sense the operation happens instantaneously when viewed by another thread.
For example the following operation is likely divided (compiler/hardware dependent):
i += 1;
because it can be observed by another thread (on hypothetical hardware and compiler) as:
load r1, i;
addi r1, #1;
store i, r1;
Two threads doing the above operation i += 1 without appropriate synchronization may produce the wrong result. Say i=0 initially, thread T1 loads T1.r1 = 0, and the thread T2 loads t2.r1 = 0. Both threads increment their respective r1s by 1 and then store the result to i. Although two increments have been performed, the value of i is still only 1 because the increment operation was divisible. Note that had there been synchronization before and after i+=1 the other thread would have waited until the operation was complete and thus would have observed an undivided operation.
Note that even a simple write may or may not be undivided:
i = 3;
store i, #3;
depending on the compiler and hardware. For example if the address of i is not aligned suitably, then an unaligned load/store has to be used which is executed by the CPU as several smaller loads/stores.
Non atomic operations may be re-ordered and may not necessarily occur in the order written in the program source code.
For example, under the "as-if" rule the compiler is allowed to re-order stores and loads as it sees fit as long as all access to volatile memory occurs in the order specified by the program "as if" the program was evaluated according to the wording in the standard. Thus non-atomic operations may be re-arranged breaking any assumptions about execution order in a multi-threaded program. This is why a seemingly innocent use of a raw int as a signaling variable in multi-threaded programming is broken, even if writes and reads may be indivisible, the ordering may break the program depending on the compiler. An atomic operation enforces ordering of the operations around it depending on what memory semantics are specified. See std::memory_order.
The CPU may also re-order your memory accesses under the memory ordering constraints of that CPU. You can find the memory ordering constraints for the x86 architecture in the Intel 64 and IA32 Architectures Software Developer Manual section 8.2 starting at page 2212.
int, char etc) are not AtomicBecause even if they under certain conditions may have indivisible store and load instructions or possibly even some arithmetic instructions, they do not guarantee the ordering of stores and loads. As such they are unsafe to use in multi-threaded contexts without proper synchronization to guarantee that the memory state observed by other threads is what you think it is at that point in time.
I hope this explains why primitive types are not atomic.
An additional info I haven't seen mentioned in the other answers so far:
If you use std::atomic<bool>, for example, and bool is actually atomic on the target architecture, then the compiler will not generate any redundant fences or locks. The same code would be generated as for a plain bool.
In other words, using std::atomic only makes the code less efficient if it is actually required to for correctness on the platform. So there is no reason to avoid it.
Implementations are free to specify that "ordinary" accesses to objects will be processed using semantics whose behavior is defined in more situations than required by the Standard. Implementations offering such semantics were used to perform tasks requiring such semantics on machines that offered them essentially "for free", decades before atomic types were added to the C or C++ language standards. If code was targeting platforms where a read of a 16-bit value which occurred at the same time as an attempt to modify it would never do anything other than yield a (possibly meaningless) 16-bit value, then C code that read a 16-bit value would likewise have no effect beyond yielding such a value. There was no perceived need for the Standard to recognize such guarantees, because nobody imagined that compilers targeting platforms that offered them, designed for tasks that would benefit from them, would ever do anything else.
Compilers like gcc, however, will sometimes replace what would appear to be a single load operation with two separate loads, and generate code which will malfunction if they don't yield the same value. As an example, ARM gcc 10.2.1, given command-line arguments -O1 -mcpu=cortex-m0 and the following function:
unsigned test(unsigned short *p)
{
unsigned short temp = *p;
temp -= temp >> 15;
return temp;
}
will generate machine code which is equivalent to the following operations (one machine instruction per line in the function body):
unsigned test(unsigned short *p)
{
unsigned r2 = *p;
unsigned r3 = 0;
unsigned r0 = *(short*)((char*)p+r3); // 16-bit signed load requires index reg
r3 >>= 16;
r0 += r2;
r0 &= 0xFFFF;
return r0;
}
If the value of *p changes from 0xFFFF to 0x0000 or vice versa between the two loads, the function may return a value which is inconsistent with the original version's load of *p yielding any 16-bit value.
© 2022 - 2024 — McMap. All rights reserved.
std::atomic: ordering with respect to other loads/stores? Either way, the C++ standard doesn't provide either guarantee, not even for acharAFAIK. On most hardware, the first (std::atomic<T>::store(val, std::memory_order_relaxed)) is free up to the size of a register (but that still doesn't make a read-modify-write++ifree if you want the whole RMW to be atomic). – Christanx = 0xaaaaaaaaaaaaaaaacompiles to two stores of0xaaaaaaaa. But constants where the two halves are different do happen to get stored with a single 64-bitstrw. GCC, See also lwn.net/Articles/793253 – Christanmemory_order_relaxedforstd::atomic? – Christanwhile(!ready) {}intoif(!ready) while(42){}. MCU programming - C++ O2 optimization breaks while loop. You only asked about tearing, not stopping the compiler from optimizing variables into registers (let alone memory ordering wrt. other operations), so I didn't mention this earlier. – Christan