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.
References:
http://www.netrino.com/node/202
http://doc.trolltech.com/4.7/qsemaphore.html
Also compare mutex/semaphores with Peterson’s algorithm and Dekker’s algorithm.
A good reference is the Art of Concurrency book. Also explore reader locks and writer locks in Qt documentation.
Exercise:
Implement a program that prints a message “An instance is running” when executed more than once in the same session.
For example, if we observe word application or Adobe reader in Windows, we can see only one instance in the task manager.
How to implement it?
Article compiled by Venki.
Please write comments if you find anything incorrect, or
you want to share more information about the topic discussed above.
1327
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
