They solve different problems even though both block on "take." A mutex is for mutual exclusion, protecting a shared resource so only one task uses it at a time, and it has two defining properties: ownership, meaning the task that took it is the owner and only that owner may give it back, and priority inheritance, meaning if a high-priority task blocks on a mutex held by a low-priority task, the kernel temporarily boosts the holder's priority so it can finish and release, bounding priority inversion. A semaphore is for signaling and counting: a binary semaphore (0/1) signals that an event occurred and has no owner, so any task or ISR can give it and a different task can take it; a counting semaphore (0..N) tracks N units of a resource or counts event occurrences. The practical rule is "mutex to protect, semaphore to signal." Misusing them causes real bugs, using a non-inheriting semaphore to guard a resource reintroduces unbounded priority inversion, and a mutex's ownership semantics break if it's "given" by a task that didn't take it. So the choice isn't cosmetic; it's about ownership and priority-inheritance semantics matching your intent.
RTOS & Real-Time Concepts · Interview question
What's the difference between a mutex and a semaphore?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
Mutexes & Semaphores
Coordinating concurrent tasks: a mutex for mutual exclusion (ownership + priority inheritance) vs a semaphore for signaling and counting, and why you give a semaphore from an ISR, not take a mutex.