信号量的用法和解释，sem_init,sem_wait

太过爱你忘了你带给我的痛 2022-10-14 12:55 114阅读 0赞

转载：[https://blog.csdn.net/htt780/article/details/77645581][https_blog.csdn.net_htt780_article_details_77645581]

信号量的数据类型为结构sem\_t，它本质上是一个长整型的数。函数sem\_init（）用来初始化一个信号量。它的原型为：

extern int sem\_init \_\_P ((sem\_t \*\_\_sem, int \_\_pshared, unsigned int \_\_value));

sem为指向信号量结构的一个指针；pshared不为０时此信号量在进程间共享，否则只能为当前进程的所有线程共享；value给出了信号量的初始值。

函数sem\_post( sem\_t \*sem )用来增加信号量的值。当有线程阻塞在这个信号量上时，调用这个函数会使其中的一个线程不在阻塞，选择机制同样是由线程的调度策略决定的。

函数sem\_wait( sem\_t \*sem )被用来阻塞当前线程直到信号量sem的值大于0，解除阻塞后将sem的值减一，表明公共资源经使用后减少。函数sem\_trywait ( sem\_t \*sem )是函数sem\_wait（）的非阻塞版本，它直接将信号量sem的值减一。

函数sem\_destroy(sem\_t \*sem)用来释放信号量sem。

信号量用sem\_init函数创建的，下面是它的说明：  
\#include<semaphore.h>  
       int sem\_init (sem\_t \*sem, int pshared, unsigned int value);  
  
       这个函数的作用是对由sem指定的信号量进行初始化，设置好它的 共享选项，并指定一个整数类型的初始值。pshared参数控制着信号量的类型。如果 pshared的值是０，就表示它是当前里程的局部信号量；否则，其它进程就能够共享这个信号量。我们现在只对不让进程共享的信号量感兴趣。　（这个参数 受版本影响），　pshared传递一个非零将会使函数调用失败。  
  
这两个函数控制着信号量的值，它们的定义如下所示：   
  
\#include <semaphore.h>   
       int sem\_wait(sem\_t \* sem);  
       int sem\_post(sem\_t \* sem);  
  
       这两个函数都要用一个由sem\_init调用初始化的信号量对象的指针做参数。  
       sem\_post函数的作用是给信号量的值加上一个“1”，它是 一个“原子操作”－－－即同时对同一个信号量做加“1”操作的两个线程是不会冲突的；而同 时对同一个文件进行读、加和写操作的两个程序就有可能会引起冲突。信号量的值永远会正确地加一个“2”－－因为有两个线程试图改变它。  
       sem\_wait函数也是一个原子操作，它的作用是从信号量的值 减去一个“1”，但它永远会先等待该信号量为一个非零值才开始做减法。也就是说，如果你对 一个值为2的信号量调用sem\_wait(),线程将会继续执行，介信号量的值将减到1。如果对一个值为0的信号量调用sem\_wait()，这个函数就 会地等待直到有其它线程增加了这个值使它不再是0为止。如果有两个线程都在sem\_wait()中等待同一个信号量变成非零值，那么当它被第三个线程增加 一个“1”时，等待线程中只有一个能够对信号量做减法并继续执行，另一个还将处于等待状态。  
        信号量这种“只用一个函数就能原子化地测试和设置”的能力下正是它的价值所在。 还有另外一个信号量函数sem\_trywait，它是sem\_wait的非阻塞搭档。  
  
        最后一个信号量函数是sem\_destroy。这个函数的作用是在我们用完信号量对它进行清理。下面的定义：  
         \#include<semaphore.h>  
         int sem\_destroy (sem\_t \*sem);  
         这个函数也使用一个信号量指针做参数，归还自己战胜的一切资源。在清理信号量的时候如果还有线程在等待它，用户就会收到一个错误。  
        与其它的函数一样，这些函数在成功时都返回“0”。

[https_blog.csdn.net_htt780_article_details_77645581]: https://blog.csdn.net/htt780/article/details/77645581