我一直在搜索，试图找出 Linux 中 c/c++ 进程的最大互斥数是多少，但没有成功。另外，有没有办法修改这个数字。我正在阅读的书提到了如何找到 Linux 中允许的最大线程数以及如何修改这个数字，但没有提到互斥锁。
【问题讨论】：
标签： c++ c multithreading locking mutex
检查这个pthread_mutex_init。
为什么没有定义限制
考虑为互斥锁和条件变量的最大数量定义符号，但被拒绝，因为这些对象的数量可能会动态变化。此外，许多实现将这些对象放入应用程序内存中。因此，没有明确的最大值。
mutex 可能具有除内存之外的成本的 cmets 中。嗯，我不知道，但我发现了一些有趣的材料：
How does a Mutex Work 上的这篇文章谈到了成本：
成本
当谈到互斥体的成本时，有几点值得关注。第一个也是非常重要的一点是等待时间。您的线程应该只花一小部分时间等待互斥体。如果他们等待太频繁，那么您将失去并发性。在最坏的情况下，许多线程总是试图锁定同一个互斥体，这可能导致性能比单个线程服务所有请求更差。这确实不是互斥锁本身的成本，而是并发编程的严重问题。
互斥锁的开销与测试和设置操作以及实现互斥锁的系统调用有关。测试和设置的成本可能非常低；对于并发处理至关重要，CPU 有充分的理由使其高效。然而，我们有点省略了另一个重要的指令：栅栏。这用于所有高级互斥锁，并且可能比测试和设置操作具有更高的成本。然而，比这更昂贵的是系统调用。您不仅要承受系统调用的上下文切换开销，而且内核现在会在其调度代码中花费一些时间。
所以我猜测他们谈论的EAGAIN 错误的成本涉及CPU 或internal kernel structures。也许两者兼而有之。也许是一些内核错误...我真的不知道。
我挑选了一些您可能感兴趣的 SO Q&A。好好读书！
【讨论】：
EAGAIN 表明资源限制是暂时的，而不是长期的。
mutexes 的工作原理。也许他们会帮助你。