我有多个使用g ++编译的应用程序,它们在Ubuntu中运行。我正在使用命名信号量来协调不同进程之间的关系。
除非 出现以下情况, 否则 所有方法都可以正常工作:如果其中一个进程调用sem_wait()或sem_timedwait()使信号量递减,然后在有机会调用之前崩溃或被杀死-9 sem_post(),则从那时起,命名的信号量“将无法使用”。
sem_wait()
sem_timedwait()
sem_post()
“不可用”,我的意思是信号量现在为零,应该将其增加到1的进程已经死亡或被杀死。
我找不到sem_*()可能告诉我上次递减的进程崩溃的API。
sem_*()
我在某处缺少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太有限,并且在发生这种情况时不会以任何方式表示。
post_sem()
的IPC工具也可当心-常用工具ipcmk,ipcrm以及ipcs只对过时的SysV信号灯。它们特别不适用于新的POSIX信号灯。
ipcmk
ipcrm
ipcs
但是看起来还有其他东西可以用来锁定东西,当应用程序以某种无法被信号处理程序捕获的方式死亡时,操作系统会自动释放这些东西。两个示例:绑定到特定端口的侦听套接字,或特定文件上的锁。
我认为锁定文件是我需要的解决方案。因此,我使用的不是a sem_wait()和sem_post()call:
lockf( fd, F_LOCK, 0 )
和
lockf( fd, F_ULOCK, 0 )
当应用程序以任何方式退出时,文件将自动关闭,这也会释放文件锁。然后,等待“信号量”的其他客户端应用程序可以按预期自由进行。
谢谢大家的帮助。