pthreads - 为什么 POSIX 将信号量标准化为系统调用，但将互斥锁和条件变量留给 Pthread（用户级别）

Question

我想出了这个困扰我的奇怪问题。为什么 POSIX 将对信号量的支持标准化为系统调用，但将条件变量和互斥锁留给 pthread 库？

这里的职责分工是什么？为什么信号量在 Pthread 包中没有标准化？为什么 POSIX 标准化的同步系统调用是信号量而不是互斥量，条件变量？

不知道。猜测性能是不将互斥锁实现为系统调用的问题。（原子硬件指令是无特权的，因此可以在用户级别实现它们。尽管 Linux 提供了 futex，但它实际上正在尝试将自旋锁优化为两相锁，朝向睡眠锁）。信号量的原因是信号量可以由不同的进程操作，而互斥锁只能由持有它的进程解锁？Semaphore 的 V 操作允许等待它的进程畅通无阻。所以信号量是由内核保存的，信号量的 id 就像文件描述符一样，是内核赋予的一种能力，这使它成为一个系统调用，而不是纯粹的用户级包。

但是条件变量呢？有什么理由在 Pthread 中指定它而不是在系统调用级别？因为它是无状态的，来源于monitor，是纯无状态的编程构造，所以可以用互斥量来实现吗？

谢谢！

标签： pthreadsposixmutexsemaphorecondition-variable

Answer 1

简短的回答：信号量和 pthread 有不同的历史。

是的：信号量可以在 pthreads 的东西（通常）全部在当前进程中的进程之间使用，或者在共享内存的进程之间使用。

从性能的角度来看：快速戳（在我的 x86_64 上）告诉我，sem_wait()并sem_post()使用简单的lock cmpxchg指令，syscall仅用于挂起/唤醒线程。pthread_mutex_t当信号量用作互斥体时，这与 -- 基本相同。

显然，信号量可以做互斥锁和条件变量不做的事情，并且您可以在进程中使用未命名的信号量——sem_init()使用pshared=0.

我猜 pthread 开发人员认为指定 apthread_sema_t将是不必要的重复。可悲的是，它确实为（更一般的）信号量即使仅在进程中使用也可能存在性能问题留下了怀疑的余地:-( 或者，确实，有些人怀疑信号量和 pthread 的东西总是可以很好地协同工作:-(