共享内存一致性的锁定机制 [英] Locking mechanisms for shared-memory consistency

问题描述

我正在开发一种使用Linux上的共享内存在两个或多个进程之间交换数据的机制.问题是需要一定程度的并发控制来维护共享内存本身上的数据完整性，并且由于我推测某个时候或其他时候我的进程可能会被杀死/崩溃，因此通用锁定机制无法正常工作，因为它们可能会离开内存处于锁定"状态并在死后立即挂起，使其他进程挂起，等待释放锁.

I'm developing a mechanism for interchanging data between two or more processes using shared memory on linux. The problem is some level of concurrency control is required to maintain data integrity on the shared memory itself, and as I'm specting that sometime or another my process could be killed/crash, common lock mechanisms dont' work because they could left the memory in a "locked" state and right after dying, making other processes hung waiting for the lock to be released.

因此，通过一些研究，我发现System V信号量具有一个名为SEM_UNDO的标志，该标志可以在程序失败时还原锁定状态，但这不能保证正常工作.另一种选择是从可能使用共享内存的所有进程中监视PID，并在发生令人讨厌的事情时对其进行一些控制，但是我不确定这是否是解决问题的正确方法.

So, doing some research I've found that System V semaphores have a flag called SEM_UNDO wich can revert the lock state when the program fails, but that's not guaranteed to work. Another option is to monitor the PID's from all processes that might use the shared memory and do some control over them if something nasty happens, but I'm not so sure if this might be the right approach to my problem.

有什么想法吗? :)

出于解释的目的，我们的应用程序需要某种IPC机制，且延迟要尽可能短.因此，我对也可以处理此要求的机制持开放态度.

for explanation purposes, our app need some kind of IPC mechanism with the smallest latency possible. So, I'm open for mechanisms that can handle this requirement also.

推荐答案

我很想知道您使用的哪个来源说不能保证SEM_UNDO起作用.我以前没有听说过.我似乎还记得阅读过一些文章，这些文章声称linux的SYSV IPC总的来说是有问题的，但是那是很久以前的事了.我想知道您的信息只是过去时代的产物.

I would be curious to know what source you used that said SEM_UNDO was not guaranteed to work. I have not heard that before. I seem to remember reading articles claiming linux's SYSV IPC in general was buggy but that was quite awhile ago. I am wondering if your info is just an artifact of times past.

要考虑的另一件事(如果我没有记错的话)是SYSV信号量可以告诉您执行信号量操作的最后一个进程的PID.如果挂起，则应该能够查询以查看持有锁的进程是否仍然存在.由于任何进程(不仅是持有锁的进程)都可以摆弄信号量，因此您可以通过这种方式进行控制.

The other thing to consider (if I remember correctly) is that SYSV semaphores have the capability to tell you the PID of the last process to perform a semaphore operation. If you hang you should be able to query to see if the process holding the lock is still alive. Since any process (not just the one holding the lock) can fiddle with semaphore you might exercise control that way.

最后，我将重点介绍消息队列.它们可能不适合您的速度要求，但通常不会比共享内存慢很多.从本质上讲，无论如何，他们还是会使用SM手动完成您必须做的所有事情，但OS会在后台进行所有操作.您可以获得几乎与同步，原子性，易用性以及经过全面测试的免费机制一样快的速度.

Lastly, I'll put in a pitch for message queues. They might not be appropriate for your speed requirements but they are generally not that much slower than shared memory. In essence they are doing everything you have to do manually with SM anyway but the OS does it all beneath the covers. You get almost as much speed with synchronization, atomicity, ease of use, and a throughly tested mechanism for free.

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