Michael Barr
Embedded.com

Editor's note: This guest editor column is the first of a series we'll be posting from Michael Barr. He also posts a blog in the blog section of Embedded.com.

The question "What's the difference between a mutex and a semaphore?" is short and easily phrased. Answering it is far more difficult. After conversations with countless embedded software developers over many years, I've concluded that even experienced RTOS users have trouble distinguishing the proper uses of mutexes and semaphores. This is unfortunate and dangerous, as misuse of either RTOS primitive can easily lead to unintended errors in embedded systems, including life-threatening products.

While the myth is that mutexes and semaphores are similar or even interchangeable, the truth is that while mutexes and semaphores have similarities in their implementation, they should always be used differently.

The most common (but nonetheless incorrect) answer is that mutexes and semaphores are very similar, with the only significant difference being that semaphores can count higher than one. Nearly all engineers seem to properly understand that a mutex is a binary flag used to protect a shared resource by ensuring mutual exclusion inside critical sections of code. But when asked to expand on how to use a "counting semaphore," most engineers-varying only in their degree of confidence-express some flavor of the textbook opinion that these are used to protect several equivalent resources.¹

It's easiest to explain why the "multiple resource" scenario is flawed by way of an analogy. If you think of a mutex as a key owned by the OS, it's easy to see that an individual mutex is analogous to the bathroom key owned by an urban coffee shop. At the coffee shop, there's one bathroom and one bathroom key. If you ask to use the bathroom when the key is not available, you are asked to wait in a queue for the key. By a very similar protocol, a mutex helps multiple tasks serialize their accesses to shared global resources and gives waiting tasks a place to wait for their turn.

This simple resource-protection protocol doesn't scale to the case of two equivalent bathrooms. If a semaphore were a generalization of a mutex able to protect two or more identical shared resources, then in our analogy it would be a basket containing two identical keys (i.e., each of the keys would work in either bathroom door).

A semaphore can't solve a multiple identical resource problem on its own. The visitor only knows that he has a key, but not which bathroom is free. If you try to use a semaphore like this, you'll find you always need other state information-itself typically a shared resource protected via a separate mutex.² It turns out the best way to design a two-bathroom coffee shop is to offer distinct keys to distinct bathrooms (e.g., men's vs. women's), which is analogous to using two distinct mutexes.