The ultimate guide to Ruby concurrency interviews. Developed by FAANG engineers, this course covers Monitors, Deferred Callbacks and problem-solving strategies for Reader-Writer and Dining Philosopher Problems.

Concurrency in Ruby is one of the most complex and advanced topics brought up during senior engineering interviews. Knowledge of concurrency and multithreading can put interviewees at a considerable advantage. This course lays the foundations of advanced concurrency and multithreading and explains concepts such as Monitors and Deferred Callbacks in depth. It also builds simple and complete solutions to popular concurrency problems that can be asked about in interviews like the Reader-Writer Problem and the Dining Philosopher Problem. While prior knowledge of concurrency is not required to follow through with this course, familiarity with the basics of Ruby would be helpful.

Ruby Concurrency for Senior Engineering Interviews

<div class="card">
# Mutex vs Semaphore

<div class="ans">
<p>Having laid the foundation of concurrent programming concepts and their associated issues, we'll now discuss the all-important mechanisms of locking and signaling in multi-threaded applications and the differences between these constructs.</p>

## Mutex

<p><span class="hi-yl">Mutex as the name hints implies <span class="i_b">mutual exclusion</span>. A mutex is used to guard shared data such as a linked-list, an array, or any primitive type.</span> A mutex allows only a single thread to access a resource or critical section.</p>

<p>Once a thread acquires a mutex, all other threads attempting to acquire the same mutex are blocked until the first thread releases the mutex. Once released, most implementations arbitrarily chose one of the waiting threads to acquire the mutex and make progress.</p>

## Semaphore

<p><span class="hi-yl">Semaphore, on the other hand, is used for limiting access to a collection of resources.</span> Think of semaphore as having a limited number of permits to give out. If a semaphore has given out all the permits it has, then any new thread that comes along requesting a permit will be blocked till an earlier thread with a permit returns it to the semaphore. A typical example would be a pool of database connections that can be handed out to requesting threads. Say there are ten available connections but 50 requesting threads. In such a scenario, a semaphore can only give out ten permits or connections at any given point.</p>

<p>A semaphore with a single permit is called a <b>binary semaphore</b> and is often thought of as equivalent to a mutex, which isn't completely correct as we'll shortly explain. <span class="hi-yl">Semaphores can also be used for signaling among threads.</span> This is an important distinction as it allows threads to work towards completing a task cooperatively. A mutex, on the other hand, is strictly limited to serializing access to shared state among competing threads.</p>

## Mutex Example
<p>The following illustration shows how two threads acquire and release a mutex one after the other to gain access to shared data. Mutex guarantees that the shared state isn't corrupted when competing threads work on it.</p> 

</div>
</div>

<div>
# Mutex vs Semaphore

<div>
<p>Having laid the foundation of concurrent programming concepts and their associated issues, we'll now discuss the all-important mechanisms of locking and signaling in multi-threaded applications and the differences between these constructs.</p>

## Mutex

<p><span>Mutex as the name hints implies <span>mutual exclusion</span>. A mutex is used to guard shared data such as a linked-list, an array, or any primitive type.</span> A mutex allows only a single thread to access a resource or critical section.</p>

<p>Once a thread acquires a mutex, all other threads attempting to acquire the same mutex are blocked until the first thread releases the mutex. Once released, most implementations arbitrarily chose one of the waiting threads to acquire the mutex and make progress.</p>

## Semaphore

<p><span>Semaphore, on the other hand, is used for limiting access to a collection of resources.</span> Think of semaphore as having a limited number of permits to give out. If a semaphore has given out all the permits it has, then any new thread that comes along requesting a permit will be blocked till an earlier thread with a permit returns it to the semaphore. A typical example would be a pool of database connections that can be handed out to requesting threads. Say there are ten available connections but 50 requesting threads. In such a scenario, a semaphore can only give out ten permits or connections at any given point.</p>

<p>A semaphore with a single permit is called a <b>binary semaphore</b> and is often thought of as equivalent to a mutex, which isn't completely correct as we'll shortly explain. <span>Semaphores can also be used for signaling among threads.</span> This is an important distinction as it allows threads to work towards completing a task cooperatively. A mutex, on the other hand, is strictly limited to serializing access to shared state among competing threads.</p>

## Mutex Example
<p>The following illustration shows how two threads acquire and release a mutex one after the other to gain access to shared data. Mutex guarantees that the shared state isn't corrupted when competing threads work on it.</p> 

</div>
</div>

The concept of and the differences between a mutex and a semaphore will befuddle most developers. In this lesson, we discuss the differences between the two most fundamental concurrency constructs offered by almost all language frameworks. Difference between a mutex and a semaphore makes a pet interview question for senior engineering positions!

The Basics

API Overview

Brief Intro to Asynchronous Programming

Interview Practice Problems

Bonus Questions

Epilogue

Mutex vs Semaphore

Mutex vs Semaphore

Mutex