Synchronization primitives: Mutex and Semaphore (Differences between Mutex and Semaphore) - Article 12

Hi Folks,

Sorry, had to take a long break. In this article, let's summarize the differences between Mutex and Semaphore and this is the last article in the series. In the coming articles we shall discuss more about OO, Design, C++, etc and revisit synchronization as and when needed.
Mutex
Semaphore
1
Mutex is a locking mechanism only to ensure mutual exclusion, that is only one thread or process is allowed to execute the code in critical section.
Semaphore can be used for locking, signalling and variety of problems as we have seen in the examples.
2
Mutex is owned and only thread that has locked the mutex can unlock it.
Semaphore does not have ownership, anybody can unlock a semaphore.
3
Process wide.
System wide.
4
Mutex is used to synchronize threads.
Semaphore is used to synchronize threads/processes.
5
Simpler to use.
Complex semantics.

To answer the "When to use what question",  mutex is preferred when only locking is required within threads, i.e., if the requirement is only to protect data or a critical section of code, mutex should be used as it is simple.

For all other synchronization problems like serialization, simultaneous access to shared resources, etc, mutex can't be used. The only other choice is semaphore.

With this, we shall ramp up synchronization.

Comments

Post a Comment

Popular posts from this blog

Synchronization primitives: Mutex and Semaphore (Serialization & Mutex problems using Semaphore) - Article 6

Hi Friends, In the previous articles, we have gained knowledge about Mutex and Semaphore. In this article, we shall see how a Semaphore can be used to solve serialization problem and Mutual Exclusion (Mutex) problem. Serialization problem: Thread 1: Event A; // Could be any code Thread 2: Event B; // Could be any code The problem is, we have to ensure that Event B or a particular code or instructions should always be executed after Event A or some other particular code. Basically, we are serializing the instructions irrespective of how the threads are scheduled to run. Solution: There are no resources here, we need to just signal, initialize Semaphore to 0. Semaphore SignalThread2 = 0; Thread 1: Event A; SignalThread2.signal(); Thread 2: SignalThread2.wait(); Event B; The code for Thread 1 and Thread 2 is as above. Irrespective of which thread is scheduled, Event A always occurs before Event B. How? Let's say Thread 2 is scheduled first, it executes
Read more

Synchronization: Discussion about Mutex and Semaphore - Article 1

This is the first article in the series about Mutex and Semaphore. In my blog, I shall follow below sequence: 1. First, I will try to explain the concept. 2. Next, we shall see what problems the concept may solve or what problems may occur if the concept is not applied. 3. Finally, we shall see how the concept will solve the problem. In this article, I will try to cover what Synchronization in Computers is all about and different problems that can occur if Synchronization is not used. First we will see the real world examples and see what Synchronization is all about. Dictionary meaning is as below: 1. To cause to occur or operate with exact coincidence in time or rate. 2. Synchronization is the coordination of events to operate a system in unison. Let's try to understand in depth. Consider below examples: 1. Imagine soldiers doing march past in a parade. - They operate at the same time and everybody march in order. - They appear synchronized. How do they do it? - Every
Read more

Synchronization primitives: Mutex and Semaphore (Readers & Writers problem) - Article 8

Hi Friends, In this article, we shall solve the Readers & Writers problem. Readers & Writers problem: There may be m writers & n readers related to a shared data structure or a record in the database (some shared data). Only one writer thread can be updating the data, but there can be many readers accessing the data. The constraints are: 1. Any number of readers can be accessing the data in critical section. 2. Only one writer thread should be allowed to update the data in critical section. Solution: int readers = 0; // Shared variable to keep track of number of readers,                  // yes this also needs to be protected Semaphore readersProtect = 1; Semaphore roomEmpty = 1; Writers thread code: roomEmpty.wait();     // Update shared data, critical section for writers roomEmpty.signal(); Readers thread code: readersProtect.wait();     readers = readers + 1;     if(readers == 1)         roomEmpty.wait(); // First reader locks and bars wri
Read more