10

I've been searching trying to find out what is the maximum number of mutexes in Linux for a c/c++ process without success. Also, is there a way to modify this number. The book I'm reading mentions how to find the max number of threads allowed in Linux and how to modify this number but no mention of mutexes.

WhatIf
  • 653
  • 2
  • 8
  • 18
  • 3
    Why do you suppose there must be a limit? And are you really considering writing a program that could be at risk of approaching any limit that there might actually be? – John Bollinger Sep 11 '15 at 19:29
  • I asked a question yesterday and someone mentioned that there is a limit. Here is the link http://stackoverflow.com/questions/32510227/synchronizing-access-to-allocated-memory the last answer – WhatIf Sep 11 '15 at 19:31

1 Answers1

15

Check this 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.

EDIT: In the comments you asked about the costs a mutex may have other than memory. Well, I don't know, but I found some interesting material about that:

This article on How does a Mutex Work says this about the costs:

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.

So I'm guessing the costs they talk about on the EAGAIN error involves either the CPU or internal kernel structures. Maybe both. Maybe some kernel error... I honestly don't know.

StackOverflow resources

I picked some SO Q&A that might interest you. Good reading!

Community
  • 1
  • 1
Enzo Ferber
  • 3,029
  • 1
  • 14
  • 24
  • From the same page "EAGAIN The system lacked the necessary resources (other than memory) to initialize another mutex. " What necessary resources other than memory they are referring to? – WhatIf Sep 11 '15 at 19:35
  • @user1886067, it's open-ended. Personally, I read it as a CYA provision, to avoid over-constraining the system. Note that the choice of `EAGAIN` for the error code suggests that the resource limitation is expected to be transitory, not long-lasting. – John Bollinger Sep 11 '15 at 19:43
  • @user1886067 See [this answer](http://stackoverflow.com/a/3652428/1928852). And read this [article](http://mortoray.com/2011/12/16/how-does-a-mutex-work-what-does-it-cost/) on how `mutexes` work. Maybe they'll help you. – Enzo Ferber Sep 11 '15 at 19:52
  • @user1886067 Added some references in my answer. Hope it helps. – Enzo Ferber Sep 11 '15 at 20:03