Are C++ Reads and Writes of an int Atomic?

Question

I have two threads, one updating an int and one reading it. This is a statistic value where the order of the reads and writes is irrelevant.

My question is, do I need to synchronize access to this multi-byte value anyway? Or, put another way, can part of the write be complete and get interrupted, and then the read happen.

For example, think of a value = 0x0000FFFF that gets incremented value of 0x00010000.

Is there a time where the value looks like 0x0001FFFF that I should be worried about? Certainly the larger the type, the more possible something like this to happen.

I've always synchronized these types of accesses, but was curious what the community thinks.

Really? I wouldn't care what the community thought. I would care what the facts are :) — sehe, Sep 28 '11 at 18:22
Interesting read on the topic: http://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-2012-Herb-Sutter-atomic-Weapons-1-of-2 — ereOn, Jul 03 '13 at 09:01
Specifically for `=`: http://stackoverflow.com/questions/8290768/is-assignment-operator-atomic — Ciro Santilli OurBigBook.com, Jun 16 '15 at 10:53
Above Video link is dead. But it is on [youtube](https://www.youtube.com/watch?v=A8eCGOqgvH4) — leosch, Mar 17 '23 at 09:46

score 65 · Answer 1 · edited Aug 12 '15 at 02:11

65

Boy, what a question. The answer to which is:

Yes, no, hmmm, well, it depends

It all comes down to the architecture of the system. On an IA32 a correctly aligned address will be an atomic operation. Unaligned writes might be atomic, it depends on the caching system in use. If the memory lies within a single L1 cache line then it is atomic, otherwise it's not. The width of the bus between the CPU and RAM can affect the atomic nature: a correctly aligned 16bit write on an 8086 was atomic whereas the same write on an 8088 wasn't because the 8088 only had an 8 bit bus whereas the 8086 had a 16 bit bus.

Also, if you're using C/C++ don't forget to mark the shared value as volatile, otherwise the optimiser will think the variable is never updated in one of your threads.

edited Aug 12 '15 at 02:11

ildjarn

62,044
9
127
211

answered Sep 10 '08 at 14:42

Skizz

69,698
10
71
108

25

The volatile keyword is not useful in multithreaded programs http://stackoverflow.com/questions/2484980/why-is-volatile-not-considered-useful-in-multithreaded-c-or-c-programming – Jul 05 '12 at 12:13
6

@IngeHenriksen: I'm not convinced by that link. – Skizz Jul 05 '12 at 13:12
another source, but unfortunately very old (it predates std::atomic): https://web.archive.org/web/20190219170904/https://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/ – Max Barraclough May 05 '20 at 21:43
1

This answer is outdated. As of C++11, unsynchronized access to an int that is not `std::atomic` is a data race, and is undefined behavior. So the current correct answer is a flat **no**. – Nate Eldredge Oct 16 '21 at 17:27
@NateEldredge: That's not entirely correct, undefined does not mean "a flat no". As I said in my answer, "it depends". Undefined just means there's no guarentee the operation is atomic, sometimes it is, sometimes it's not. The code is not going to be portable if you make assumptions about the atomic nature, but if you're targeting a fixed hardware and software configuration and comment the code appropriately then the assumption might work for you. But, like I said, it won;t be truely portable. – Skizz Oct 18 '21 at 06:58

Adam Mitz · Accepted Answer · 2011-12-09T17:55:24.500

48

At first one might think that reads and writes of the native machine size are atomic but there are a number of issues to deal with including cache coherency between processors/cores. Use atomic operations like Interlocked* on Windows and the equivalent on Linux. C++0x will have an "atomic" template to wrap these in a nice and cross-platform interface. For now if you are using a platform abstraction layer it may provide these functions. ACE does, see the class template ACE_Atomic_Op.

edited Dec 09 '11 at 17:55

answered Sep 10 '08 at 15:37

Adam Mitz

6,025
1
29
28

The document of ACE_Atomic_Op has moved - it can now be found at http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/ACE/ace/Atomic_Op.inl – Byron Dec 09 '11 at 16:41

score 11 · Answer 3 · answered Sep 10 '08 at 14:41

11

IF you're reading/writing 4-byte value AND it is DWORD-aligned in memory AND you're running on the I32 architecture, THEN reads and writes are atomic.

answered Sep 10 '08 at 14:41

gabr

26,580
9
75
141

3

Where in the Intel architecture software developer's manuals is this stated? – Daniel Trebbien Jan 03 '11 at 16:56
2

@DanielTrebbien: perhaps see http://stackoverflow.com/questions/5002046/atomicity-in-c-myth-or-reality – sehe Sep 28 '11 at 18:23
1

This is not true at the level of C++. The underlying machine instructions are atomic, but the compiler is allowed to optimize in ways that would break atomicity. – Nate Eldredge Oct 16 '21 at 17:44

score 9 · Answer 4 · answered Sep 10 '08 at 14:31

Yes, you need to synchronize accesses. In C++0x it will be a data race, and undefined behaviour. With POSIX threads it's already undefined behaviour.

In practice, you might get bad values if the data type is larger than the native word size. Also, another thread might never see the value written due to optimizations moving the read and/or write.

score 3 · Answer 5 · answered Sep 10 '08 at 14:38

You must synchronize, but on certain architectures there are efficient ways to do it.

Best is to use subroutines (perhaps masked behind macros) so that you can conditionally replace implementations with platform-specific ones.

The Linux kernel already has some of this code.

score 3 · Answer 6 · answered Sep 16 '08 at 21:46

3

On Windows, Interlocked***Exchange***Add is guaranteed to be atomic.

answered Sep 16 '08 at 21:46

Andrew Stein

12,880
5
35
43

score 2 · Answer 7 · 2012-07-03T15:05:18.490

2

To echo what everyone said upstairs, the language pre-C++0x cannot guarantee anything about shared memory access from multiple threads. Any guarantees would be up to the compiler.

edited Jul 03 '12 at 15:05

answered Sep 11 '08 at 16:07

score 0 · Answer 8 · answered Oct 22 '13 at 09:13

0

Definitively NO ! That answer from our highest C++ authority, M. Boost:
Operations on "ordinary" variables are not guaranteed to be atomic.

answered Oct 22 '13 at 09:13

Jean Davy

2,062
1
19
24

2

that link only says `arithmetic` operation which consists of a read-update-write sequence on 'ordinary' variables are not atomic, not whether `read` or `write` operation on 'ordinary' variables are atomic or not. – D3Hunter Feb 24 '18 at 07:48

score 0 · Answer 9 · edited Aug 02 '10 at 02:12

0

Lets take this example

int x;
x++;
x=x+5;

The first statement is assumed to be atomic because it translates to a single INC assembly directive that takes a single CPU cycle. However, the second assignment requires several operations so it's clearly not an atomic operation.

Another e.g,

x=5;

Again, you have to disassemble the code to see what exactly happens here.

edited Aug 02 '10 at 02:12

sth

222,467
53
283
367

answered Jul 31 '10 at 16:39

siddhusingh

1,832
4
25
30

2

But the compiler could optimize it into `x+=6`. – tc. Aug 13 '10 at 14:02

score 0 · Answer 10 · answered Aug 19 '10 at 09:22

0

tc, I think the moment you use a constant ( like 6) , the instruction wouldn't be completed in one machine cycle. Try to see the instruction set of x+=6 as compared to x++

answered Aug 19 '10 at 09:22

siddhusingh

1,832
4
25
30

score 0 · Answer 11 · answered Sep 10 '08 at 14:30

0

No, they aren't (or at least you can't assume they are). Having said that, there are some tricks to do this atomically, but they typically aren't portable (see Compare-and-swap).

answered Sep 10 '08 at 14:30

Leon Timmermans

30,029
2
61
110

score 0 · Answer 12 · edited May 23 '17 at 12:17

0

I agree with many and especially Jason. On windows, one would likely use InterlockedAdd and its friends.

edited May 23 '17 at 12:17

Community

1
1

answered Sep 10 '08 at 15:00

kenny

21,522
8
49
87

score 0 · Answer 13 · answered Sep 12 '08 at 01:03

0

Asside from the cache issue mentioned above...

If you port the code to a processor with a smaller register size it will not be atomic anymore.

IMO, threading issues are too thorny to risk it.

answered Sep 12 '08 at 01:03

JeffV

52,985
32
103
124

score 0 · Answer 14 · answered Mar 28 '12 at 07:39

0

Some people think that ++c is atomic, but have a eye on the assembly generated. For example with 'gcc -S' :

movl    cpt.1586(%rip), %eax
addl    $1, %eax
movl    %eax, cpt.1586(%rip)

To increment an int, the compiler first load it into a register, and stores it back into the memory. This is not atomic.

answered Mar 28 '12 at 07:39

etham

3,158
2
16
13

2

This is not an issue if only one thread is writing to the variable, since there's no tearing. – Ben Voigt Apr 17 '12 at 22:40

score -1 · Answer 15 · answered May 09 '10 at 01:47

-1

The only portable way is to use the sig_atomic_t type defined in signal.h header for your compiler. In most C and C++ implementations, that is an int. Then declare your variable as "volatile sig_atomic_t."

answered May 09 '10 at 01:47

Edward Howorka

17

volatile doesn't do what you think it does http://stackoverflow.com/questions/2484980/why-is-volatile-not-considered-useful-in-multithreaded-c-or-c-programming – Sam Miller Jul 08 '10 at 02:48
`sig_atomic_t` is atomic with respect to signals, but not with respect to threads. Since C++11, accessing such an object from multiple threads is a data race and UB. – Nate Eldredge Oct 16 '21 at 17:29

score -1 · Answer 16 · answered May 30 '21 at 14:05

-1

Reads and writes are atomic, but you also need to worry about the compiler re-ordering your code. Compiler optimizations may violate happens-before relationship of statements in your code. By using atomic you don't have to worry about that. ... atomic i;

soap_status = GOT_RESPONSE ; i = 1

In the above example, the variable 'i' will only be set to 1 after we get a soap response.

answered May 30 '21 at 14:05

coredump

19
3

This is not true. Reads and writes of `int` are not guaranteed atomic in standard C++, and the resulting data race causes undefined behavior. – Nate Eldredge Oct 16 '21 at 17:28

Are C++ Reads and Writes of an int Atomic?

16 Answers16

Linked