Blogroll

ADs

Blogger news

Saturday, July 26, 2014

Problem

What is the difference between mutex and semaphore?

Solution

Mutexes, monitors and semaphores are all synchronization mechanisms i.e. they are used to mediate access to a shared resource between multiple processes or threads (referred to as processes henceforth).
However, they are used differently:

Mutex

Used to provide mutual exclusion i.e. ensures at most one process can do something (like execute a section of code, or access a variable) at a time.
A famous analogy is the bathroom key in a Starbucks; only one person can acquire it, therefore only that one person may enter and use the bathroom. Everybody else who wants to use the bathroom has to wait till the key is available again.

Monitor
Provides mutual exclusion to an object i.e. at any point in time, at most one process may access any of the object's members/ execute any of its methods. This is ideologically similar to a mutex for an entire OOP instance; no part of the instance can be touched by more than one process at a time. Monitors can provide condition variables which are used for signaling purposes, in addition to "pure" mutual exclusion.

Semaphores

Is the number of free identical toilet
keys. Example, say we have four
toilets with identical locks and keys.
The semaphore count - the count of
keys - is set to 4 at beginning (all
four toilets are free), then the count
value is decremented as people are
coming in. If all toilets are full,
ie. there are no free keys left, the
semaphore count is 0. Now, when eq.
one person leaves the toilet,
semaphore is increased to 1 (one free
key), and given to the next person in
the queue.

Key difference - Ownership and signalling

Mutex can be released only by thread that had acquired it, while you can
signal semaphore from any other thread (or process), so semaphores are
more suitable for some synchronization problems like producer-consumer. So, semaphores have no notion of ownership, as any thread can release a semaphore.

Strictly speaking, a mutex is locking mechanism
used to synchronize access to a resource. Only one task (can be a
thread or process based on OS abstraction) can acquire the mutex. It
means there will be ownership associated with mutex, and only the owner
can release the lock (mutex).
Semaphore is signaling mechanism
(“I am done, you can carry on” kind of signal). For example, if you are
listening songs (assume it as one task) on your mobile and at the same
time your friend called you, an interrupt will be triggered upon which
an interrupt service routine (ISR) will signal the call processing task
to wakeup.General Questions:1. Can a thread acquire more than one lock (Mutex)?
Yes, it is possible that a thread will be in need of more than one
resource, hence the locks. If any lock is not available the thread will
wait (block) on the lock.2. Can a mutex be locked more than once?
A mutex is a lock. Only one state (locked/unlocked) is associated with it. However, a recursive mutex
can be locked more than once (POSIX complaint systems), in which a
count is associated with it, yet retains only one state
(locked/unlocked). The programmer must unlock the mutex as many number
times as it was locked.3. What will happen if a non-recursive mutex is locked more than once.
Deadlock. If a thread which had already locked a mutex, tries to lock
the mutex again, it will enter into the waiting list of that mutex,
which results in deadlock. It is because no other thread can unlock the
mutex. An operating system implementer can exercise care in identifying
the owner of mutex and return if it is already locked by same thread to
prevent deadlocks.4. Are binary semaphore and mutex same?
No. We will suggest to treat them separately, as it was explained
signalling vs locking mechanisms. But a binary semaphore may experience
the same critical issues (e.g. priority inversion) associated with
mutex. We will cover these later article.
A programmer can prefer mutex rather than creating a semaphore with count 1.5. What is a mutex and critical section?
Some operating systems use the same word critical section in
the API. Usually a mutex is costly operation due to protection
protocols associated with it. At last, the objective of mutex is atomic
access. There are other ways to achieve atomic access like disabling
interrupts which can be much faster but ruins responsiveness. The
alternate API makes use of disabling interrupts.6. What are events?
The semantics of mutex, semaphore, event, critical section, etc… are
same. All are synchronization primitives. Based on their cost in using
them they are different. We should consult the OS documentation for
exact details.7. Can we acquire mutex/semaphore in an Interrupt Service Routine?
An ISR will run asynchronously in the context of current running thread. It is not recommended
to query (blocking call) the availability of synchronization primitives
in an ISR. The ISR are meant be short, the call to mutex/semaphore may
block the current running thread. However, an ISR can signal a semaphore
or unlock a mutex.8. What we mean by “thread blocking on mutex/semaphore” when they are not available?
Every synchronization primitive will have waiting list associated
with it. When the resource is not available, the requesting thread will
be moved from the running list of processor to the waiting list of the
synchronization primitive. When the resource is available, the higher
priority thread on the waiting list will get resource (more precisely,
it depends on the scheduling policies).9. Is it necessary that a thread must block always when resource is not available?
Not necessarily. If the design is sure ‘what has to be done when resource is not available‘,
the thread can take up that work (a different code branch). To support
application requirements the OS provides non-blocking API.
For example POSIX pthread_mutex_trylock() API. When the mutex is not
available the function will return immediately where as the API
pthread_mutex_lock() will block the thread till resource is available.