System V 和 Posix 信号量之间的差异
使用 System V 和 Posix 信号量之间有何权衡？
What are the trade-offs between using a System V and a Posix semaphore?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
使用 System V 和 Posix 信号量之间有何权衡？
What are the trade-offs between using a System V and a Posix semaphore?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（4）
来自 O'Reilly< /a>:
From O'Reilly:
在单独的进程（而不是线程）中使用 POSIX 共享/命名信号量的两个主要问题：
当持有信号量锁的不同进程死亡时，POSIX 信号量不提供唤醒等待进程的机制。 缺乏清理可能会导致僵尸信号量，这将导致任何其他或后续尝试使用它们的进程陷入死锁。 也没有 POSIX 方式列出操作系统中的信号量来尝试识别和清理它们。 SysV IPC 上的 POSIX 部分确实指定了 ipcs 和 ipcrm 工具来列出和操作全局 SysV IPC 资源。 POSIX IPC 没有指定这样的工具甚至机制，尽管在 Linux 上这些资源通常可以在 /shm 下找到。 这意味着在错误的时间向错误的进程发出 KILL 信号可能会导致整个交互进程系统死锁，直到重新启动为止。
另一个缺点是 POSIX 信号量使用文件语义。 这意味着可以有多个具有相同名称但处于不同状态的共享信号量。 例如，进程调用 sem_open，然后调用 sem_unlink，然后再调用 sem_close。 此过程仍然可以使用信号量，就像在关闭打开的文件之前取消链接一样。 进程 2 在进程 1 的 sem_unlink 和 sem_close 调用之间的同一个信号量上调用 sem_open，并且（根据文档）获得一个具有相同名称的全新信号量，但处于与进程 1 不同的状态。两个具有相同名称的共享信号量独立操作违背了共享信号量的目的。
上述限制使得 POSIX 共享信号量在现实系统中无法使用，并且不能保证永远不会发送无法捕获的信号。 假设控制将使用给定信号量的所有代码，可以通过仔细编码来缓解限制二。 坦率地说，他们将其纳入标准确实有点令人惊讶。
Two major problems with POSIX shared/named semaphores used in separate processes (not threads):
POSIX semaphores provide no mechanism to wake a waiting process when a different process dies while holding a semaphore lock. This lack of cleanup can lead to zombie semaphores which will cause any other or subsequent process that tries to use them to deadlock. There is also no POSIX way of listing the semaphores in the OS to attempt to identify and clean them up. The POSIX section on SysV IPC does specify the ipcs and ipcrm tools to list and manipulate global SysV IPC resources. No such tools or even mechanisms are specified for POSIX IPC, though on Linux these resources can often be found under /shm. This means that a KILL signal to the wrong process at the wrong time can deadlock an entire system of interacting processes until reboot.
Another disadvantage is the use of file semantics for POSIX semaphores. The implication is that there can be more than one shared semaphore with the same name, but in different states. For example a process calls sem_open, then sem_unlink before sem_close. This process can still use the semaphore just like unlinking an open file before closing it. Process 2 calls sem_open on the same semaphore between the sem_unlink and sem_close calls of process 1, and (according to documentation) gets a brand new semaphore with the same name, but in a different state than process 1. Two shared semaphores with the same name operating independently defeats the purpose of shared semaphores.
Limitation one above makes POSIX shared semaphores unusable in a real-world system without a guarantee that uncatchable signals can never be sent. Limitation two can be mitigated by careful coding, assuming control over all code that will use a given semaphore. Frankly, its more than a bit surprising they made it into the standard as they are.
我知道这已经过时了，但为了那些仍在阅读 Google 提供的这篇文章的人的利益，我发现使用 System V 信号量而不是 POSIX（系统级）信号量的第一个原因是能够以以下方式获取信号量资源：无论进程如何退出，都会由内核自动返回。
我同意很少使用多个（原子）信号量操作（尽管它们在暂存期间可能很有用），并且 System V 接口很奇怪，但根本没有办法使用 POSIX 信号量可靠地实现相同的清理语义。
I know this is old, but for the benefit of those still reading this courtesy of Google, the #1 reason I find to use System V semaphores over POSIX (system-level) semaphores is the ability to acquire the semaphore resource in a way which is automatically returned by the kernel NO MATTER HOW THE PROCESS EXITS.
I agree that the multiple (atomic) semaphore operations are rarely used (although they can be useful during staging), and that the System V interface is bizarre, but there's simply no way of reliably achieving the same clean-up semantics with POSIX semaphores.
关于性能，POSIX 信号量基于 futex Linux。 这使得它们比 SYSV 信号量更加高效。
SYSV 信号量需要系统系统调用来执行 P()/V() 操作。 因此，这会系统地触发用户到内核空间的上下文切换，反之亦然。
在 POSIX 版本中，如果信号量上没有争用，底层 futex 会使调用者停留在用户空间中（P()/V() 操作是在用户空间中使用可用的原子操作完成的）。 仅在发生争用时才会切换到内核模式。 因此，在使用 POSIX 信号量的应用程序中，用户到内核空间上下文切换的数量较少，反之亦然。 这使他们更快。
Concerning the performances, POSIX semaphores are based on the futex under Linux. This makes them much more efficient than SYSV semaphores.
The SYSV semaphores require systematic system calls for the P()/V() operations. So, this systematically triggers user to kernel space context switches and conversely.
In the POSIX version, the underlying futex makes the caller stay in user space if there is no contention on the semaphore (the P()/V() operations are done in user space with available atomic operations). The switch into kernel mode is done only in case of contention. So, the number of user to kernel space context switches and conversely are less numerous in applications using POSIX semaphores. This makes them faster.