Critical Section vs. Mutex

Posted by Jeremy Cooke

 

Both critical sections and mutex objects can be used to synchronize code execution in a Windows CE system. Judicious use of these techniques is necessary to prevent sharing conflicts over system resources through synchronized access. But why would a programmer choose one method over the other?

 

A critical section is defined as a segment of code that can be run by at most one thread at any instance of time. All code that accesses a shared resource should be placed within a critical section in order to synchronize access to the resource. In effect, mutually exclusive access to the resource is guaranteed if all accesses are guarded by the same critical section.

 

A mutex object is ‘signaled’ when it is not owned by a thread. A thread takes ownership of the synchronizing mutex object prior to accessing a shared resource. If the resource is already in use by another thread, then access will be blocked. Exclusive access can be guaranteed provided all accesses to the resource are guarded by the same mutex object.

 

Now to highlight the differences: In general, mutex objects are more CPU intensive and slower to use than critical sections due to a larger amount of bookkeeping, and the deep execution path into the kernel taken to acquire a mutex. The equivalent functions for accessing a critical section remain in thread context, and consist of merely checking and incrementing/decrementing lock-count related data. This makes critical sections light weight, fast, and easy to use for thread synchronization within a process. The primary benefit of using a mutex object is that a mutex can be named and shared across process boundaries.

 

Best practices to optimize for performance include:

• Minimizing the need to synchronize across process boundaries during software design
• Minimizing the use of mutex objects whenever possible
• Using critical sections for synchronization whenever possible

 

More information on critical section and mutex APIs can be found on MSDN:

• Critical Sections: https://msdn2.microsoft.com/en-us/library/aa910712.aspx
• Mutex’s and other synchronization functions: https://msdn2.microsoft.com/en-us/library/aa909196.aspx

Comments

• Anonymous
  March 29, 2007
  Nice posting on CS vs Mutexes.  One critical point that wasn't made clear is that critical sections only provide synchronization within a single process.  While they do limit access to a section of code to a single thread, that is only true for the set of threads within a process.  If the code is in a dll that can be loaded by multiple processes, then multiple threads from different processes can take ownership of the CS simultaneously.Dean
• Anonymous
  March 30, 2007
  Dean,I just want to clarify one thing above. If the dll is loaded in multiple processes, then the critical section object is unique per process. So in reality even if multiple threads from different processes might be executing the same section of the code in the dll, they would be operating on per-process data (including the critical section object exposed by the dll).I hope that is what you meant by the statement that different processes can take ownership of the CS simultaneously. In that case the CS would be different for each process.thx.-Upender
• Anonymous
  April 01, 2007
  What do you use for thread synchronization - mutex or critical section? Check out this blog post from
• Anonymous
  April 02, 2007
  Sue Loh's article on lock convoys is an important piece of information to reference after reading this article.  There is a dark side to the behavior of these helpfuls syncronization objects that needs to be understood and avoided.  http://blogs.msdn.com/sloh/archive/2005/05/27/422605.aspx#1266395
• Anonymous
  April 02, 2007
  Hi Upender,Yes, that is what I meant although I said it poorly.  I was thinking of critical sections used to protect some type of global resource.  In this case, there is still only one global resource to protect regardless of process, so the fact that each process has it's own critical section object means that the synchronization mechanism would fail.  Dean
• Anonymous
  April 02, 2007
  Dean,When you say "global resource", if you are referring to system wide data (process agnostic data), then yes critical sections is not the right choice in that case. One could use named mutex in this case to protect access to the shared data or other system wide synchronization mechanisms.-Upender
• Anonymous
  April 03, 2007
  Yes, that's what I meant.  Bad choice of words again, sorry! I'm thinking of things like cpu registers etc.Dean