记录一次linux信号量sem_t使用bug

linux提供了互斥量pthread_mutex_t(pthread库) 用于线程间同步，进程间同步提供了信号量sem_t。如果把pthread_mutex_t放到共享内存中，并将其属性设置为PTHREAD_PROCESS_SHARED，则也能实现进程间的同步，相对而言比较麻烦。一般直接使用信号量更加方便。

这里讨论使用具名信号量以便在无血缘关系的进程之间做同步，主要涉及下面5个函数：

sem_open();//打开或者创建信号量
sem_wait();//获取信号量
sem_post();//挂出信号量
sem_close();//关闭信号量
sem_unlink();//销毁信号量

其中sem_unlink()的行为比较让人迷惑，linux内核文档描述为：

DESCRIPTION
       sem_unlink() removes the named semaphore referred to by name.  The semaphore name is removed immediately.  The
       semaphore is destroyed once all other processes that have the semaphore open close it.

意思是执行该函数，会立即移除信号量的id名，并尝试销毁对应的信号量实体，只有所有打开了该信号量的进程都执行了sem_close()，执行sem_unlink()时才会真正销毁这个信号量。问题就出现了，id名与信号量实体可能出现分离，因为当某个进程A关闭了信号量(也就是执行了sem_close)并尝试执行sem_unlink的时候，并不能确保其他进程关闭了信号量，结果是信号量实体无法被真正销毁，它依然在内核中存在，且其他使用该信号量实体的进程依然可以工作正常。问题是，当进程A再次打开这个信号量时(使用sem_open()，id名不变)，已经无法通过id名找到之前那个信号量实体了，打开的是一个全新的信号量，虽然id名与之前一样，内容却已经没有关联了。

        这样一来，进程A就无法与其他进程同步了。只有其他进程也执行一次sem_close，并重新打开这个id名(sem_open())，才能重新连接到进程A打开的那个信号量实体，继续同步。因此“The semaphore name is removed immediately”,应该理解为"立即解除name 与信号量实体的绑定关系"，且解除之后无法重新绑定。

        在使用共享内存的过程中，shmctl(id,IPC_RMID,NULL)移除共享内存，好像也有类似的问题，没有实测过。

总结：

        通常当一个进程退出时，需要关闭已经打开的信号量(sem_close)，如果信号量属于这个进程（在这个进程里面create），还应该执行sem_unlink；如果信号量的归属权不是该进程，则只应该执行关闭。

        现实使用的时候，进程可能异常挂掉退出，没有执行到sem_close这一步，甚至还没有来得及挂出信号量(sem_post)程序就挂了，问题比较复杂，不仅可能存在数据安全，还很有可能造成死锁。所以最好是当某个进程重启了，其他相关进程也重启一下，确保所有进程打开的是同一个信号量实体，可以一定程度避免信号量和共享内存连接异常的问题。

        当然，最好是不要让程序有异常挂掉的情况，应该做好异常捕获和处理，减少程序未定义行为。