在这种特殊情况下，我是否需要共享内存中的原子类型？

Question

I have multiple processes using boost shared memory. The writer processes will write to an array in shared memory like so:

void push(int32_t val_)
{
    int nextIndex = _currentIndex.fetch_add(1,std::memory_order_relaxed);
    _buffer[nextIndex] = val_;
}
//val_ is guaranteed to be >=1
//_buffer is an array of int32_t in shared memory initialized to 0

The single reader process will read like so:

void process()
{
    int idx=0;
    while(running)
    {
      int32_t val = _buffer[idx];
      if(val)
      {
          //do some work...
          ++idx;
      }
    }
}            

According to boost: "Changes in that address range are automatically seen by other process that also have mapped the same shared memory object."

My question is, assuming _buffer is aligned properly, can _buffer simply be an array of int32_t or is it absolutely necessary to define _buffer as an array of std::atomic ? Writing to int32_t is atomic on x86 assuming alignment is correct and boost guarantees other processes will see the update.

CPU info:

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                24
On-line CPU(s) list:   0-23
Thread(s) per core:    1
Core(s) per socket:    12
Socket(s):             2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 63
Stepping:              2
CPU MHz:               2596.945
BogoMIPS:              5193.42
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              30720K
NUMA node0 CPU(s):     0-5,12-17
NUMA node1 CPU(s):     6-11,18-23

Answer 1

As you wrote yourself, one thread writes to some memory location:

_buffer[nextIndex] = val_;

And a different thread reads that memory location:

  int32_t val = _buffer[idx];

According to the standard, that memory address has to be synchronized or else it's undefined behaviour.

That array has to be either an array of atomics, a simple array protected by a mutex or a fast spinlock or any other array that its reads and writes are synchronized.

Answer 2

TL;DR : Even then, you do need to synchronize your accesses. And use atomics, not ordinary mutexes.

There are a few of issues here:

First, you have a writer thread and a reader thread, writing to and reading from the same memory location. This means that access to that location must be protected (using locks, atomic operations, fences, whatever.) The fact that these threads are in different processes doesn't enter into it. You still need to resolve the data race.

Second, although the Boost documentation says that changes are automatically seen by other processes that map the region, but I believe that's just a simplification. The shared memory library cannot provide stronger guarantees about shared memory among different processes than those that exist for different threads in the same process. All the same problems may still arise: your reads/writes might be reordered by the compiler or the CPU or even the memory system, or even omitted completely or combined with other reads/writes. And there are cache and MMU effects to be considered.

So even though your data is correctly aligned, and writes to that datatype are atomic on your architecture, it doesn't provide any safety against incorrect behavior resulting from data race if you don't protect your accesses. There is no magic here; if you had to synchronize/protect/atomicize your accesses when you had threads, you need to do the same for processes as well. You probably have to do even more.

Third, the synchronization primitives that work for threads inside the same process might not (and probably will not) work across different processes. Atomic operations (or types, as C++ has implemented them) do work. Memory fences might work too, depending on what you are doing. IIRC though, Boost's shared memory library provides special synchronization primitives that work across process boundaries (if placed inside the shared area.)