如果pthread正在锁定共享资源。
是否存在等待pthread_mutex可能遇到的威胁？
类似于并行pthreads的限制，时间限制，事件......
答案 0 :(得分：1)
正如您在规范中看到的那样，例如here，pthread_mutex_lock()具有int返回值。除了琐碎/明显的错误原因，例如“无效论证”等，还有一个实际上可以被视为“威胁”。特别是对不检查返回值的人构成威胁。
此威胁是返回值EAGAIN，如果未正确捕获，可能会导致程序出现故障，访问互斥锁应该保护的资源，而不会获取互斥锁。例如，EAGAIN可能发生，如果进程收到System V“信号”，并且该代码的线程受其影响。
通常，与Posix线程并行使用Unix System V构造（如信号）至少是危险的。在Unix System V中，线程不存在，很明显，进程的单个主线程被“中断”并用于处理信号（使用堆栈切换到信号堆栈）。主线程的任何内核端阻塞都被中断，阻塞函数返回EAGAIN并且必须在处理信号后重新发出其调用。
因此，不幸的是，在Posix / Unix系统上唯一简单的编码方式涉及到可能阻塞的任何东西的大量while循环。
while( EAGAIN == pthread_mutex_lock(...) );
不这样做意味着您的代码只能用于明显完全控制信号行为的应用程序中。例如禁用所有信号或使用其他方法确保执行此代码的线程不会受到影响。
除此之外，互斥锁是系统资源（内核对象），可用数量不是无限的，但通常不用担心。我希望其他答案能够详细阐述这些限制。
编辑在过去几年中，文档似乎发生了变化。现在他们说，EAGAIN与递归锁的限制有关，并且EINTR不会发生。在过去，至少有一些系统/文件符合我上面的解释。
也是新的（至少对我来说）：
如果信号传递给等待互斥锁的线程，则从信号处理程序返回后，线程将继续等待互斥锁，就像它没有被中断一样。
好吧，也许他们学到的东西，因为我上次被迫使用这样的系统。