我正在开发一种在Linux上使用共享内存在两个或多个进程之间交换数据的机制。问题是需要一定程度的并发控制来维护共享内存本身上的数据完整性，并且由于我期望某个时候或其他时间我的进程可能会被杀死/崩溃，因此通用锁定机制无法正常工作，因为它们可能会留下内存处于“锁定”状态并在快死之后，使其他进程挂起，等待释放该锁。
因此，通过做一些研究，我发现System V信号量具有一个名为SEM_UNDO的标志，该标志可以在程序失败时还原锁定状态，但不能保证该标志能正常工作。另一个选择是从可能使用共享内存的所有进程中监视PID，并在发生令人讨厌的事情时对其进行一些控制，但是我不确定这是否是解决问题的正确方法。
有任何想法吗？
编辑:出于解释的目的，我们的应用程序需要某种IPC机制，并尽可能减少延迟。因此，我对也可以处理此要求的机制持开放态度。
最佳答案
我很想知道您使用什么来源说SEM_UNDO不能保证正常工作。我以前没有听说过。我似乎还记得阅读过一些文章，这些文章声称linux的SYSV IPC通常是错误的，但是那是很久以前的事了。我想知道您的信息只是过去时代的产物。
要考虑的另一件事(如果我没有记错的话)是SYSV信号量具有告诉您执行信号量操作的最后一个进程的PID的能力。如果挂起，则应该能够查询以查看持有锁的进程是否仍然存在。由于任何过程(不仅是持有锁的过程)都可以摆弄信号量，因此您可以通过这种方式进行控制。
最后，我将介绍消息队列。它们可能不适合您的速度要求，但通常不会比共享内存慢很多。从本质上讲，无论如何，他们还是会使用SM手动完成您必须做的所有事情，但OS会在后台完全完成。您可以获得几乎与同步，原子性，易用性以及经过全面测试的免费机制一样快的速度。