C + + 是一个 int 原子的读写吗？

我有两个线程，一个更新 int，一个读取它。这是一个统计值，其中读取和写入的顺序是不相关的。

我的问题是，我是否需要同步对这个多字节值的访问？或者，换句话说，可以写的一部分完成，被打断，然后读发生。

例如，考虑一个值 = 0x0000FFFF，它的增量值为0x00010000。

有没有一段时间，值看起来像0x0001FFFF，我应该担心吗？当然，类型越大，发生这种情况的可能性就越大。

我总是同步这些类型的访问，但是很好奇社区是怎么想的。

38025 次浏览
小开

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).

小开

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.

小开

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.

小开

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.

小开

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.

小开

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

小开
最佳答案

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.

小开

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.

小开

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.

小开

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

小开

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."

小开

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.

小开

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++

小开

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.

小开

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

小开

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.


提交答案