Dear sir/Mrs.
I have a program with 27 Mutexes.
all mutexes are created with the same sequence:
1. Setting an atribute using pthread_mutexattr_setpshared funtion with the PTHREAD_MUTEX_RECURSIVE_NP.
2. Initialization of the Mutex using the pthread_mutex_init.

Except one mutex, 26 times, the process is OK.
for one mutex initialization, I get the error code 95.
Of course, later, any LOCK/UNLOCK operation fails with the error code 130 and 131 respectively.

We use the Red-Hat OS.

Thanks in advance.
Yehuda

I see a big design-problem in the idea of "27 mutexes." (Could you simply be running out of them?)

Even if your application really does have 27 distinct flows-of-control that really can be used in parallel, pragmatically speaking you don't need to have a distinct mutex for each one. You can "group" them as you see fit. That is to say, "in order to do this, or, that, or that, you need to hold 'mutex #1.'" (You make this decision "by agreement," and follow it carefully as you write the code.)

Mutexes are sometimes also arranged in a hierarchy (again, "by agreement"), so that you must never try to grab "this" mutex unless you are holding "that" one.

Consider, as an example, the locking strategy that is used within the Linux kernel. Although "the kernel, of course, is different from user-land," and must deal with a more complex situation overall, the design ideas still generally hold.

Finally, I find that the actual number of mutexes needed is quite small ... usually one, maybe two or three. The more elaborate you try to get in your mutual-exclusion design, the (much) greater becomes the risk of deadlock, race conditions, inefficiency, and so on. It's probably better to allow a thread to have to wait a few microseconds longer, if it keeps your overall design simple. The number "27" tells me: change your design.

1 members found this post helpful.