semop

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ghosc/article/details/5758094
    函数：int semop(int id , struct sembuf array[], nops);
 
    信号量
    优点：比文件锁有优势，效率不是高那么一点，起码不用打开文件关闭文件这些耗时间的工作。
    缺点：一旦锁定，若在解锁之前出现程序崩溃等segment fault问题，将直接导致锁定的信号量无法恢复，形成永久占用。文件锁则没有这个问题，进程的退出将导致文件描述符关闭，在该描述符上进行的锁定操作就自行解除了。
 
    办法解决：在加锁的时候会有一个UNDO的设置，也就是在调用semop的时候指定操作结构体当中可以放置一个UNDO参数，
 
    通常都是这样去调用的：
        semop(iSemID, &stLocksem, 1);

    其中stLocksem就是定义的一个操作结构体，原型为：
        struct sembuf{
            unsighed  short  sem_num;
            short            sem_op;
            short            sem_flg;
        };

        一般定义为：
        struct sembuf stLocksem={0, -1, SEM_UNDO} , stUnlocksem={0, 1, SEM_UNDO};
 
    这样的UNDO选项会让内核记录一个与调用进程相关的UNDO记录，如果该进程崩溃，则根据这个进程的UNDO记录自动恢复相应信号量的计数值。
 
    不过有个问题：
    对于SEM_UNDO来说，内核记录的信息是跟进程相关的。一个进程在lock的时候设置一个UNDO，那么对应该进程的UNDO计数就多一个，unlock的时候设置一个UNDO，那么计数就减一个。对于临界区互斥的应用而言，lock和unlock都是在一个进程当中完成，于是UNDO可以切实发挥作用。
    然而，如果是一个进程lock，而另一个进程unlock，那么使用UNDO就不起作用了，而且由于都是单边操作，导致UNDO计数对单一进程而言，
    只朝一个方向发展，最后必定是超过内核限制值，这时会出现ERANGE(34)的错误。
————————————————
版权声明：本文为CSDN博主「ghosc」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/ghosc/article/details/5758094