原子访问共享内存 [英] Atomic access to shared memory
问题描述
我在多个进程之间有一个共享内存，以一定的方式对内存进行插值。
例如：
I have a shared memory between multiple processes that interpets the memory in a certain way. Ex:
DataBlock {
int counter;
double value1;
double ... }
我想让计数器更新/原子地。和一个内存释放发生在那个地址。
如果我不使用共享内存，例如，它会像
What I want is for the counter to be updated/incremented atomically. And for a memory release to happen on that address. If I werent using shared memory, for example, it would be something like
std::atomic<int> counter;
atomic_store(counter, newvalue, std::memory_order_release); // perform release operation on the affected memory location making the write visible to other threads
如何实现这个随机存储位置（解释为DataBlock计数器>上面）。我可以保证地址是根据架构（x86 linux）所要求的
How do I achieve this for a random memory location (interpreted to be DataBlock counter >above). I can guarantee the address is aligned as required by the architecture (x86 linux)
- 使更新原子 - 如何？ （例如atomicupdate（addr，newvalue））
- 多核的内存同步（即memorysync（addr）） - 只有我能看到的是使用std :: atomic_thread_fence（std :: memory_order_release ） - 但是这将建立所有原子和轻松的原子存储的内存同步排序 - 这对我来说是过分 - 我只是想让计数器位置同步。
欣赏任何想法。
推荐答案
-
互斥体可以在共享内存中创建和/或被创建为跨过程。 Pthread有一个特殊的创建标志，我不记得如果使用共享内存，或者你然后共享一个句柄。 linuxfutex可以直接使用共享内存（注意用户地址可能不同，但底层的实际地址应该是一样的）
Mutexes can be created in shared memory and/or created to be cross-process. Pthread has a special creation flag, I can't remember if that uses shared memory, or you then share a handle. The linux "futex" can use shared memory directly (note the user address may differ, but the underlying real address should be the same)
内存而不是过程变量。也就是说，你的芯片不会关心哪些程序正在修改变量，因此最低级别的原子自然是跨进程的。这同样适用于栅栏。
Hardware atomics work on memory and not process variables. That is, your chip won't care which programs are modifying the variables, the lowest level atomics will thus naturally be cross-process. The same applies to fences.
C ++ 11无法指定跨进程原子。然而，如果它们是无锁的（检查标志），很难看到编译器如何实现它们，使得跨进程将不工作。
C++11 fails to specify cross-process atomics. However, if they are lock-free (check the flag) it is hard to see how a compiler could implement them such that cross-process wouldn't work. But you'd be placing a lot of faith in your tool-chain and final platform.
CPU依赖性还可以跟踪实际内存地址，因此只要
CPU dependency guarantees also track real memory addresses, so as long as your program would be correct in a threaded form it should also be correct in its multi-process form (with respect to visibility).
Kerrek是正确的，而且它的多进程形式也是正确的。抽象机没有真正提到多个进程。然而，它的同步细节以这样的方式写，使得它们同样适用于进程间处理，因为它们对多线程。这涉及到＃3：编译器很难解决这个问题。
Kerrek is correct, the abstract machine doesn't really mention multiple processes. However, its synchronization details are written in a way such that they'd equally apply to inter-process as they do to multi-thread. This relates to #3: it'd be hard for a compiler to screw this up.
是没有标准兼容的方式做到这一点。然而，根据标准定义多线程的方式，你可以为一个高质量的编译器做很多假设。
Short answer, there is no standards compliant way to do this. However, leaning on the way the standard defines mutli-threads there are a lot of assumptions you can make for a quality compiler.
最大的问题是一个原子是否可以简单地在共享内存（placement new）和工作中分配。显然，这只会工作，如果它是一个真正的硬件原子。然而我的猜测是，使用质量编译器/ libary C ++ atomics应该在共享内存中找到工作。
The biggest question is whether an atomic can simply be allocated in shared memory (placement new) and work. Obviously this would only work if it is a true hardware atomic. My guess however is that with a quality compiler/libary the C++ atomics should work find in shared memory.
有乐趣验证行为。 ：）
Have fun verifying behaviour. :)
这篇关于原子访问共享内存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
