How efficient is locking and unlocked mutex? What is the cost of a mutex?

by

I have the choice in between either having a bunch of mutexes or a single one for an object.

If you have many threads and the access to the object happens often, then multiple locks would increase parallelism. At the cost of maintainability, since more locking means more debugging of the locking.

How efficient is it to lock a mutex? I.e. how much assembler instructions are there likely and how much time do they take (in the case that the mutex is unlocked)?

The precise assembler instructions are the least overhead of a mutex – the memory/cache coherency guarantees are the main overhead. And less often a particular lock is taken – better.

Mutex is made of two major parts (oversimplifying): (1) a flag indicating whether the mutex is locked or not and (2) wait queue.

Change of the flag is just few instructions and normally done without system call. If mutex is locked, syscall will happen to add the calling thread into wait queue and start the waiting. Unlocking, if the wait queue is empty, is cheap but otherwise needs a syscall to wake up one of the waiting processes. (On some systems cheap/fast syscalls are used to implement the mutexes, they become slow (normal) system calls only in case of contention.)

Locking unlocked mutex is really cheap. Unlocking mutex w/o contention is cheap too.

How much does a mutex cost? Is it a problem to have really a lot of mutexes? Or can I just throw as much mutex variables in my code as I have int variables and it doesn’t really matter?

You can throw as much mutex variables into your code as you wish. You are only limited by the amount of memory you application can allocate.

Summary. User-space locks (and the mutexes in particular) are cheap and not subjected to any system limit. But too many of them spells nightmare for debugging. Simple table:

  1. Less locks means more contentions (slow syscalls, CPU stalls) and lesser parallelism
  2. Less locks means less problems debugging multi-threading problems.
  3. More locks means less contentions and higher parallelism
  4. More locks means more chances of running into undebugable deadlocks.

A balanced locking scheme for application should be found and maintained, generally balancing the #2 and the #3.

(*) The problem with less very often locked mutexes is that if you have too much locking in your application, it causes to much of the inter-CPU/core traffic to flush the mutex memory from the data cache of other CPUs to guarantee the cache coherency. The cache flushes are like light-weight interrupts and handled by CPUs transparently – but they do introduce so called stalls (search for “stall”).

And the stalls are what makes the locking code to run slowly, often without any apparent indication why application is slow. (Some arch provide the inter-CPU/core traffic stats, some not.)

To avoid the problem, people generally resort to large number of locks to decrease the probability of lock contentions and to avoid the stall. That is the reason why the cheap user space locking, not subjected to the system limits, exists.

More Related Contents:

  1. How efficient is locking an unlocked mutex? What is the cost of a mutex?
  2. Recursive Lock (Mutex) vs Non-Recursive Lock (Mutex)
  3. What is a mutex?
  4. Concurrent HashSet in .NET Framework?
  5. What is the Re-entrant lock and concept in general?
  6. What is a deadlock?
  7. Is it possible to use mutex in multiprocessing case on Linux/UNIX ?
  8. What are the differences between various threading synchronization options in C#?
  9. Is non-blocking I/O really faster than multi-threaded blocking I/O? How?
  10. Can x86 reorder a narrow store with a wider load that fully contains it?
  11. When is a condition variable needed, isn’t a mutex enough?
  12. Which is more efficient, basic mutex lock or atomic integer?
  13. Is there an advantage to use a Synchronized Method instead of a Synchronized Block?
  14. Volatile vs. Interlocked vs. lock
  15. Difference between -pthread and -lpthread while compiling
  16. Mutex example / tutorial? [closed]
  17. what is the correct way to implement a QThread… (example please…)
  18. CoreData: warning: Unable to load class named
  19. How to cancel Future in Scala?
  20. How would you implement your own reader/writer lock in C++11?
  21. Does an x86 CPU reorder instructions?
  22. What is a “thread” (really)?
  23. Grasping the Node JS alternative to multithreading
  24. How, if at all, do Erlang Processes map to Kernel Threads?
  25. Number of threads used by Go runtime
  26. fork in multi-threaded program
  27. C# manual lock/unlock
  28. Thread references require static lifetime?
  29. What happens when different CPU cores write to the same RAM address without synchronization?
  30. Can we have race conditions in a single-thread program?

Leave a Comment