31

I am doing experiments with IPC, especially with Mutex, Semaphore and Spin Lock. What I learnt is Mutex is used for Asynchronous Locking (with sleeping (as per theories I read on NET)) Mechanism, Semaphore are Synchronous Locking (with Signaling and Sleeping) Mechanism, and Spin Locks are Synchronous but Non-sleeping Mechanism.

Can anyone help me to clarify these stuff deeply? And another doubt is about Mutex, when I wrote program with thread & mutex, while one thread is running another thread is not in Sleep state but it continuously tries to acquire the Lock. So Mutex is sleeping or Non-sleeping???

Novice
  • 540
  • 2
  • 8
  • 21
  • I think you would also like to read this post also. http://stackoverflow.com/questions/5869825/when-should-one-use-a-spinlock-instead-of-mutex – Ritesh Feb 24 '15 at 19:38

3 Answers3

67

First, remember the goal of these 'synchronizing objects' :

These objects were designed to provide an efficient and coherent use of 'shared data' between more than 1 thread among 1 process or from different processes.

These objects can be 'acquired' or 'released'.

That is it!!! End of story!!!

Now, if it helps to you, let me put my grain of sand:

1) Critical Section= User object used for allowing the execution of just one active thread from many others within one process. The other non selected threads (@ acquiring this object) are put to sleep.

[No interprocess capability, very primitive object].

2) Mutex Semaphore (aka Mutex)= Kernel object used for allowing the execution of just one active thread from many others, within one process or among different processes. The other non selected threads (@ acquiring this object) are put to sleep. This object supports thread ownership, thread termination notification, recursion (multiple 'acquire' calls from same thread) and 'priority inversion avoidance'.

[Interprocess capability, very safe to use, a kind of 'high level' synchronization object].

3) Counting Semaphore (aka Semaphore)= Kernel object used for allowing the execution of a group of active threads from many others, within one process or among different processes. The other non selected threads (@ acquiring this object) are put to sleep.

[Interprocess capability however not very safe to use because it lacks following 'mutex' attributes: thread termination notification, recursion?, 'priority inversion avoidance'?, etc].

4) And now, talking about 'spinlocks', first some definitions:

Critical Region= A region of memory shared by 2 or more processes.

Lock= A variable whose value allows or denies the entrance to a 'critical region'. (It could be implemented as a simple 'boolean flag').

Busy waiting= Continuosly testing of a variable until some value appears.

Finally:

Spin-lock (aka Spinlock)= A lock which uses busy waiting. (The acquiring of the lock is made by xchg or similar atomic operations).

[No thread sleeping, mostly used at kernel level only. Ineffcient for User level code].

As a last comment, I am not sure but I can bet you some big bucks that the above first 3 synchronizing objects (#1, #2 and #3) make use of this simple beast (#4) as part of their implementation.

Have a good day!.

References:

-Real-Time Concepts for Embedded Systems by Qing Li with Caroline Yao (CMP Books).

-Modern Operating Systems (3rd) by Andrew Tanenbaum (Pearson Education International).

-Programming Applications for Microsoft Windows (4th) by Jeffrey Richter (Microsoft Programming Series).

fante
  • 2,475
  • 1
  • 16
  • 17
  • Re "Critical section .. the other threads are put to sleep." - only true for *very primitive* implementation of a critical section, where interrupts are disabled upon entry of that section. See [Wikipedia - Critical section](https://en.wikipedia.org/wiki/Critical_section) for discussion of that implementation, as well as the alternative of using a semaphore for more efficient implementation, of what is still referred to as a "critical section" of code. – ToolmakerSteve Feb 02 '17 at 05:00
  • 2
    ... later definitions here are even more **misleading** when they say "other threads are put to sleep". That implies to me that other threads *can't run at all*, which completely misses the point of these mechanisms. Specifically, any thread that needs to use the shared resource (protected by one of these mechanisms) must indeed be blocked (put to sleep), but *threads that are not using the shared resource, are not put to sleep*. – ToolmakerSteve Feb 02 '17 at 05:04
  • ... the distinction between mutex and semaphore is ..weak.. [don't know if that is a problem with the references, or with the re-statement in this answer]. For a clearer distinction, see https://barrgroup.com/Embedded-Systems/How-To/RTOS-Mutex-Semaphore The key sentence "The correct use of a semaphore is for signaling from one task to another. A mutex is meant to be taken and released, always in that order, by each task that uses the shared resource it protects. By contrast, tasks that use semaphores either signal or wait—not both. " – ToolmakerSteve Feb 02 '17 at 05:09
  • @ToolmakerSteve, the distinction between a mutex and semaphore is weak? Really?. Please, I beg you to read one of the book from the references. The Li & Yao book is superb to get your ideas clear. – fante Feb 06 '17 at 12:56
  • @ToolmakerSteve, however I should say (as you refer in your comments) that these objects are used to provide 'signaling' between threads too. Let me think about it and I will add that feature to my answer. – fante Feb 06 '17 at 13:12
  • @fante - I apologize, calling that mutex/counting distinction `weak` was uncalled for. What is missing, is that they are - or rather should be - used quite differently. Of necessity, a `mutex` is owned by a thread, which must unlock it when it is done. So code is `lock mutex / do stuff / unlock mutex`. By contrast, a semaphore can be passed around; it is like a baton in a baton race. I agree with https://barrgroup.com/Embedded-Systems/How-To/RTOS-Mutex-Semaphore - that semaphores can have count > 1 is an historical accident, that should not be used... – ToolmakerSteve Feb 16 '17 at 21:09
  • ... Semaphore with count=1 is a valuable tool to have, when need to pass ownership from a producer to a consumer. Semaphores with count>1 should probably never be used when multi-threading. Instead, use a pool of mutexes. The clue is if code is doing `get semaphor / do stuff / release semaphor`, that is probably an unsafe attempt to use a counting semaphore. It is an unfortunate historical evolution that someone noticed that semaphores could "easily" have a count, thus converting a safe concept (passing around a baton or token) into a dangerous concept. – ToolmakerSteve Feb 16 '17 at 21:14
  • ... an unrelated quibble, "The other non selected threads are put to sleep." needs clarifying. Taken literally, as soon as one executes a mutex or semaphore, the system would go around to other running threads, putting them to sleep. I'm sure that is not what you meant. – ToolmakerSteve Feb 16 '17 at 21:21
  • .. sorry to belabor the mutex/semaphore distinction. In many, perhaps most, discussions, the ability of the semaphore to have count > 1 is what is emphasized. Then the book/article/stackoverflow_post will have an example of a semaphore with count > 1. Carrying on the dangerous abuse of semaphores. And obscuring the more useful difference, which is that a semaphore is similar to a token or baton, that can be passed around. – ToolmakerSteve Feb 16 '17 at 21:27
  • ... and sorry for being so negative. Re the issues you mention in *safely* using a counting semaphore (count > 1) (due to lack of guarantees that a mutex has): can you incorporate into your answer a good reference as to *how* to use one safely? Such a reference would be more helpful to others, than my grumbling about details... – ToolmakerSteve Feb 16 '17 at 22:24
  • @ToolmakerSteve, don't worry bro for your comments. They are really useful!!!. And I understand what you mean. Yes, my answer is a little bit misleading. The 'counting semaphore' (as you infer and suggest) is more useful as a 'signaling' object than an object to provide some kind of 'exclusion'. I am fixing my answer. In the meantime, if you have the resources please check Chapter 6 of the 'Qing Li & Caroline Yao' book. – fante Feb 17 '17 at 21:03
  • @ToolmakerSteve, According to that book, the 'counting semaphore' is useful when dealing with a 'Credit-Tracking Synchronization' situation. For example, here we have 2 tasks: tWaitTask() & tSignalTask() which are using a 'synchronizing' object (which one?). And suppose you have this tSignalTask() running more frequently (ie: because of higher priority, maybe an ISR) and who needs to record or 'count' each of its 'signaling' occurrences (maybe because each time it runs & signals means a new 'data packet' has arrived!). What 'synchronizing' object will you use here? – fante Feb 17 '17 at 21:05
  • @ToolmakerSteve, .. A 'counting semaphore' fits right!!!. Therefore, a 'counting semaphore' (CS1) is created with an 'initial count' of 0 (Unavailable). Now, suppose tWaitTask() runs first and when it calls the 'acquire(CS1) or wait(CS1)' kernel call it gets BLOCKED because there are no 'tokens' available yet. Time goes on and tSignalTask() gets to run, do some processing and before finishing it calls to 'release(CS1) or signal(CS1)'. This action makes tWaitTask() to get READY again and eventually it will run. – fante Feb 17 '17 at 21:06
  • @ToolmakerSteve, .. In the meantime it may happen that tSignalTask() gets to run again many times due to its higher priority. However, as you can see tWaitTask() will never 'miss' any 'data packet' if before processing each one it calls to 'acquire(CS1) or wait(CS1)'. // This book also mentions another situation (Multiple Shared-Resource-Access Synchronization) where it fits right this object but I am not sure about it. The reason? It is what Barr mentions in the reference you provided above. There will be the question which resource to access from within the ones which have the tokens anyway. – fante Feb 17 '17 at 21:17
3

Here is a great explanation of the difference between semaphores and mutexes:

http://blog.feabhas.com/2009/09/mutex-vs-semaphores-–-part-1-semaphores/

The short answer has to do with ownership at least with binary semaphores but I suggest you read the entire article.

smyrgl
  • 864
  • 6
  • 12
  • 1
    Another interesting post:http://stackoverflow.com/questions/5869825/when-should-one-use-a-spinlock-instead-of-mutex – Ritesh Feb 24 '15 at 19:40
0

Mutex is the locking mechanism while the semaphore is the wait and signal mechanism. Both have different applications.

There is a very good explanation given by the IISC professor.

Link for video

Build Succeeded
  • 1,153
  • 1
  • 10
  • 24