1) A binary semaphore can be a Mutex but a Mutex can never be binary semaphore. This simply means that a binary semaphore can be used as Mutex, but a Mutex can never exhibit the functionality of binary semaphore.
2) No one owns binary semaphores, whereas Mutex are owned and the owner is held responsible for them. This is an important distinction from a debugging perspective.
3) In case the of Mutex, the thread that owns the Mutex is responsible for freeing it. However, in the case of binary semaphores, this condition is not required.
Any other thread can signal to free the binary semaphore by using the sem_post()function.
4) Another difference that would matter to developers is that binary semaphores are system-wide and
remain in the form of files on the filesystem, unless otherwise cleaned up. Mutex are process-wide and get cleaned up automatically when a process exits.
5) The nature of binary semaphores makes it possible to use them in synchronizing related and unrelated process, as well as between threads. Mutex can be used
only in synchronizing between threads and at most between related processes (the pthread implementation of the latest kernel comes with a feature
that allows Mutex to be used between related process).
6) According to the kernel documentation, Mutex are lighter when compared to binary semaphores. What this means is that a program with binary semaphore usage has
a higher memory footprint when compared to a program having Mutex.
7) From a usage perspective, Mutex has simpler semantics when compared to binary semaphores.
Mutex can not be used for unrelated process.
Semaphore is signaling mechanism
mutex is locking mechanism