Hi all,

Does anyone know of any kind of issues for using a large number of mutexes (pthreads) between multiple threads. Questions that would arise are "Does the overhead of using mutexes from small numbers to large number of mutexes increase linearly for every new mutex being used?"

Suppose as an example, there is a hash table where a single mutex controls access to it and then there is a mutex on every node of the hash table and multiple threads access this hash table, what kind of additional overhead would come up? Some of you would think this is a bad idea, so please share your thoughts.

Basically the idea is to also ask whether using large number of mutexes causes significant problems in the processor working efficiently between all threads.

Thanks for reading!

Well, I've seen mutex creation being referred to as expensive. I don't know exactly how expensive it is, but it must not be cheap because the pthreads library offers a static one built at compile-time to reduce run-time overhead. This makes me think there's more to it than a simple malloc().

So, ultimately, it boils down to what you mean by "overhead". If you mean memory consumption, then yes - the memory consumption of your mutexes will increase linearly with the number of mutexes, just as you would expect. If by overhead, you mean processor time spent locking/unlocking/obtaining a mutex, then I would guess these would always run in constant time. Since the very nature of a mutex is to provide a check which cannot be interrupted, then it must be an atomic operation, else hardware interrupts could interrupt it. Therefore, a mutex lock/unlock must run in constant time. The number of threads running should have no effect on the memory consumption or lock/unlocking time of a mutex.

So, ultimately, the primary things to take into consideration are:
(1) How large are the objects stored in the hash table. If they are several Kb, then a mutex probably isn't too much overhead. If it's a char, probably not worth it.
(2) How often is concurrent access to the hash table going to cause blocking.

You may want to look at another form of data protection for a hash table. A Read/Write lock may be more appropriate. It seems that things stored in hash tables are generally read a lot more often than they are written to, so allowing concurrent reads could be beneficial.

Thanks a lot for your detailed reply PatrickNew. That gives me a more comfortable view of using mutexes.

Another question still in my mind is whether keeping large number of mutexes can become a headache for the operating system to be able to simply maintain (this headache perhaps maybe dependant on implementation details of the mutex). For example, there might be a limit on the number of mutexes after which the OS performance decreases (not refering to the fixed time taken in (un)locking but I don't have a clear idea of what could happen). Perhaps this question is just my own paranoia :{

Okay, upon further research, I was wrong and mutexes need not be atomic. However, they have no knowledge of each other and are thus not impacted by the number created. Whether or not mutexes are a headache for the OS I think depends largely on implementation. For instance, I can write a "pthreads" mutex which only runs on i386, but puts *no* load on the operating system, by simply having mutexes be int's, have lock/unlock/trylock be handled with the i386 atomic get/set/test instructions. So here I would guess "implementation defined", but I have a hard time seeing a better way - so I'm guessing that implementations on architectures with atomic get/set/test (most non-embedded architectures) probably use that.