我一直在搜索，试图找出 Linux 中 c/c++ 进程的最大互斥数是多少，但没有成功。另外，有没有办法修改这个数字。我正在阅读的书提到了如何找到 Linux 中允许的最大线程数以及如何修改这个数字但没有提到互斥量。
最佳答案
检查这个pthread_mutex_init .
Why No Limits are Defined
Defining symbols for the maximum number of mutexes and condition variables was considered but rejected because the number of these objects may change dynamically. Furthermore, many implementations place these objects into application memory; thus, there is no explicit maximum.
编辑:在评论中，您询问了
互斥锁 可能具有不同于 内存的成本。好吧，我不知道，但我发现了一些有趣的 Material :
这篇文章 How does a Mutex Work说到成本:
The Costs
There are a few points of interest when it comes to the cost of a mutex. The first, and very vital point, is waiting time. Your threads should spend only a fraction of their time waiting on mutexes. If they are waiting too often then you are losing concurrency. In a worst case scenario many threads always trying to lock the same mutex may result in performance worse than a single thread serving all requests. This really isn’t a cost of the mutex itself, but a serious concern with concurrent programming.
The overhead costs of a mutex relate to the test-and-set operation and the system call that implements a mutex. The test-and-set is likely very low cost; being essential to concurrent processing the CPUs have good reason to make it efficient. We’ve kind of omitted another important instruction however: the fence. This is used in all high-level mutexes and may have a higher cost than the test-and-set operation. More costlier than even that however is the system call. Not only do you suffer the context switch overhead of the system call, the kernel now spends some time in its scheduling code.
所以我猜测他们谈论的关于EAGAIN 错误的成本涉及CPU 或内部内核结构。也许两者都有。也许是一些内核错误...老实说我不知道。
StackOverflow 资源
我选择了一些您可能感兴趣的 SO Q&A。好好读书!
关于c++ - c/c++ Linux 允许的最大互斥量，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32530754/