求关于共享内存锁定问题的文章 [英] Seeking articles on shared memory locking issues

问题描述

我正在审查一些代码，并对所使用的技术感到怀疑.

I'm reviewing some code and feel suspicious of the technique being used.

在linux环境下，有两个进程附加多个共享内存段.第一个进程周期性地加载一个新的集合要共享的文件，并将共享内存 ID (shmid) 写入主"共享内存段中的一个位置.第二道工序不断读取这个主"位置并使用 shmid 附加其他共享段.

In a linux environment, there are two processes that attach multiple shared memory segments. The first process periodically loads a new set of files to be shared, and writes the shared memory id (shmid) into a location in the "master" shared memory segment. The second process continually reads this "master" location and uses the shmid to attach the other shared segments.

在多 CPU 主机上，在我看来它可能取决于实现如果一个进程试图读取内存时会发生什么被对方写.但也许硬件级总线锁定可以防止电线上的碎片?阅读过程是否得到了没关系一个很快就会改变的值，只有读取被破坏才重要既不是旧值也不是新值的东西.这是一个边缘情况:只有 32 位被写入和读取.

On a multi-cpu host, it seems to me it might be implementation dependent as to what happens if one process tries to read the memory while it's being written by the other. But perhaps hardware-level bus locking prevents mangled bits on the wire? It wouldn't matter if the reading process got a very-soon-to-be-changed value, it would only matter if the read was corrupted to something that was neither the old value nor the new value. This is an edge case: only 32 bits are being written and read.

谷歌搜索 shmat 的东西并没有让我找到任何确定的东西区域.

Googling for shmat stuff hasn't led me to anything that's definitive in this area.

我强烈怀疑它不安全或不健全，而我真正想要的是就像是一些指向详细描述问题的文章的指针.

I suspect strongly it's not safe or sane, and what I'd really like is some pointers to articles that describe the problems in detail.

推荐答案

这是合法的——因为在操作系统中不会阻止你这样做.

It is legal -- as in the OS won't stop you from doing it.

但是它聪明吗?不，你应该有某种类型的同步.

But is it smart? No, you should have some type of synchronization.

不会有电线上的错位".它们将以 1 或 0 的形式出现.但是没有什么可以说在另一个进程尝试读取它们之前将写出所有位.并且无法保证它们的写入速度和读取速度.

There wouldn't be "mangled bits on the wire". They will come out either as ones or zeros. But there's nothing to say that all your bits will be written out before another process tries to read them. And there are NO guarantees on how fast they'll be written vs how fast they'll be read.

您应该始终假设 2 个进程(或线程)的操作之间绝对没有关系.

You should always assume there is absolutely NO relationship between the actions of 2 processes (or threads for that matter).

硬件级总线锁定不会发生，除非你做对了.使您的编译器/库/操作系统/cpu 正确运行可能比预期更难.编写同步原语是为了确保它正确发生.

Hardware level bus locking does not happen unless you get it right. It can be harder then expected to make your compiler / library / os / cpu get it right. Synchronization primitives are written to makes sure it happens right.

锁定将使其安全，而且并不难做到.所以就去做吧.

Locking will make it safe, and it's not that hard to do. So just do it.

@unknown - 自从我的答案发布后，问题有所改变.但是，您描述的行为明显依赖于平台(硬件、操作系统、库和编译器).

@unknown - The question has changed somewhat since my answer was posted. However, the behavior you describe is defiantly platform (hardware, os, library and compiler) dependent.

如果不给编译器特定的指令，实际上不能保证一次写出 32 位.想象一下 32 位字未在字边界上对齐的情况.这种未对齐的访问在 x86 上是可以接受的，而在 x68 的情况下，访问被 cpu 变成了一系列对齐的访问.

Without giving the compiler specific instructions, you are actually not guaranteed to have 32 bits written out in one shot. Imagine a situation where the 32 bit word is not aligned on a word boundary. This unaligned access is acceptable on x86, and in the case of the x68, the access is turned into a series of aligned accesses by the cpu.

在这些操作之间可能会发生中断.如果上下文切换发生在中间，一些位会被写入，有些则不会.砰，你死定了.

An interrupt can occurs between those operations. If a context switch happens in the middle, some of the bits are written, some aren't. Bang, You're Dead.

另外，让我们考虑一下 16 位 CPU 或 64 位 CPU.两者都仍然很受欢迎，不一定像您想的那样工作.

Also, lets think about 16 bit cpus or 64 bit cpus. Both of which are still popular and don't necessarily work the way you think.

因此，实际上您可能会遇到其他一些 cpu-core 选择写入 1/2 字大小的值"的情况.如果您不使用同步，您编写的代码就好像这种类型的事情会发生一样.

So, actually you can have a situation where "some other cpu-core picks up a word sized value 1/2 written to". You write you code as if this type of thing is expected to happen if you are not using synchronization.

现在，有多种方法可以预写您的文章，以确保您写出完整的单词.这些方法属于同步类别，创建同步原语是最好留给库、编译器、操作系统和硬件设计人员的类型.特别是如果你对可移植性感兴趣(你应该这样做，即使你从来没有移植你的代码)

Now, there are ways to preform your writes to make sure that you get a whole word written out. Those methods fall under the category of synchronization, and creating synchronization primitives is the type of thing that's best left to the library, compiler, os, and hardware designers. Especially if you are interested in portability (which you should be, even if you never port your code)

这篇关于求关于共享内存锁定问题的文章的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！