当将信号量递减至零的进程崩溃时，如何恢复信号量？

我有多个使用 g++ 编译的应用程序，在 Ubuntu 中运行。我使用命名信号量来协调不同的进程。

一切正常except在以下情况下：如果其中一个进程调用sem_wait() or sem_timedwait()减少信号量，然后在有机会调用之前崩溃或被杀死 -9sem_post()，那么从那一刻起，指定的信号量就“不可用”了。

我所说的“不可用”是指信号量计数现在为零，而本应将其增加回 1 的进程已死亡或被终止。

我找不到sem_*()API 可能会告诉我上次减少它的进程已经崩溃。

我是否在某处缺少 API？

这是我打开命名信号量的方法：

sem_t *sem = sem_open( "/testing",
    O_CREAT     |   // create the semaphore if it does not already exist
    O_CLOEXEC   ,   // close on execute
    S_IRWXU     |   // permissions:  user
    S_IRWXG     |   // permissions:  group
    S_IRWXO     ,   // permissions:  other
    1           );  // initial value of the semaphore

这是我减少它的方法：

struct timespec timeout = { 0, 0 };
clock_gettime( CLOCK_REALTIME, &timeout );
timeout.tv_sec += 5;

if ( sem_timedwait( sem, &timeout ) )
{
    throw "timeout while waiting for semaphore";
}

事实证明，没有办法可靠地恢复信号量。当然，任何人都可以post_sem()到指定的信号量以使计数再次增加到零以上，但是如何判断何时需要这样的恢复？提供的 API 太有限，并且没有以任何方式指示这种情况何时发生。

注意还有可用的ipc工具——常用工具ipcmk, ipcrm, and ipcs仅适用于过时的 SysV 信号量。它们特别不适用于新的 POSIX 信号量。

但看起来还有其他东西可以用来锁定东西，当应用程序以信号处理程序无法捕获的方式终止时，操作系统会自动释放这些东西。两个示例：绑定到特定端口的侦听套接字，或特定文件上的锁定。

我认为文件锁定是我需要的解决方案。所以而不是sem_wait() and sem_post()打电话，我正在使用：

lockf( fd, F_LOCK, 0 )

and

lockf( fd, F_ULOCK, 0 )

当应用程序以任何方式退出时，文件将自动关闭，这也会释放文件锁。然后等待“信号量”的其他客户端应用程序可以按预期自由地继续。

谢谢你们的帮助，伙计们。

UPDATE:

12 年后，我想我应该指出 posix 互斥体确实具有“鲁棒”属性。这样，如果互斥锁的所有者被杀死或退出，下一个锁定互斥锁的用户将获得非错误返回值EOWNERDEAD，允许恢复互斥锁。这将使其类似于文件和套接字锁定解决方案。抬头pthread_mutexattr_setrobust() and pthread_mutex_consistent()了解详情。谢谢 Reinier Torenbeek 的提示。