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">
 # Read Write Lock
 <div class="ans">
Imagine you have an application where you have multiple readers and a single writer. You are asked to design a lock that lets multiple readers read at the same time, but only one writer writes at a time.
 </div>
</div>

<div class="card">
 # Solution
 <div class="ans">
First of all, let us define the APIs our class will expose. We'll need two for writer and two for reader. These are: 

<ul>
 <li>acquireReadLock</li>
 <li>releaseReadLock</li>
 <li>acquireWriteLock</li>
 <li>releaseWriteLock</li>
</ul> 

This problem becomes simple if you think about each case:
 
<ol>
 <li>Before we allow a reader to enter the critical section, we need to make sure that there's no writer in progress. It is ok to have other readers in the critical section since they aren't making any modifications.</li>
 <li>Before we allow a writer to enter the critical section, we need to make sure that there's no reader or writer in the critical section.</li>
</ol>

Let's start with the reader use case. We can have multiple readers acquire the read lock and to keep track of all of them; we'll need a count. We increment this count whenever a reader acquires a read lock and decrement it whenever a reader releases it.

Releasing the read lock is easy, but before we acquire the read lock, we need to be sure that no other writer is currently writing. Again, we'll need some variable to keep track of whether a writer is writing. Since only a single writer can write at a given point in time, we can just keep a boolean variable to denote if the write lock is acquired or not.

Additionally, we'll also need a condition variable for the readers and writers to wait while the other party is in progress. We'll use the associated mutex lock with the condition variable to guard the sections of the code where we manipulate any shared variables. Let's translate what we have discussed so far into code.


```ruby
class ReadersWriteLock

 def initialize()
 @condVar = ConditionVariable.new
 @mutex = Mutex.new
 @writeInProgress = false
 @readers = 0
 end

 def acquireReadLock()
 end

 def releaseReadLock()
 end

 def acquireWriteLock()
 end

 def releaseWriteLock()
 end

end
```


Next we'll take a stab at the <code class="mthd">acquireReadLock()</code> method.


```ruby
 def acquireReadLock()
 @mutex.lock()

 while @writeInProgress == true
 @condVar.wait(@mutex)
 end

 @readers += 1
 @mutex.unlock()
 end
```


Note that multiple reader threads can invoke the above method and not block if no write is in progress thus satisfying the condition that multiple readers can read at the same time. Next let's examine the <code class="mthd">releaseReadLock()</code> method.


```ruby
 def releaseReadLock()
 @mutex.lock()
 @readers -= 1
 @condVar.broadcast()
 @mutex.unlock()
 end
```


When releasing the read lock, each reader decrements the <code class="mthd">readers</code> count. Since multiple reader threads can modify the shared readers' count, we guard it with the mutex lock. Also, we notify any writer threads waiting on the condition variable. Note that a 
reader notifies the condition variable even if the readers' count is not zero. We can improve the code as follows, but the above implementation will also work.


```ruby
 def releaseReadLock()
 @mutex.lock()

 @readers -= 1

 if @readers == 0
 @condVar.broadcast()
 end
 @mutex.unlock()
 end
```


Now let's turn to the writer thread case. A writer should only proceed if no reader or writer is currently in progress, implying we need to check for two conditions. The implementation is as follows:

```ruby
 def acquireWriteLock()
 @mutex.lock()

 while @readers != 0 or @writeInProgress == true
 @condVar.wait(@mutex)
 end
 @writeInProgress = true

 @mutex.unlock()
 end
```


The last piece is the <code class="mthd">releaseWriteLock()</code> which sets the <code class="mthd">writeInProgress</code> to false and notifies any reader threads waiting on the condition variable.


```ruby
 def releaseWriteLock()
 @mutex.lock()

 @writeInProgress = false
 @condVar.broadcast()

 @mutex.unlock()
 end
```


The complete code appears below in the code widget.

<div>
 # Read Write Lock
 <div>
Imagine you have an application where you have multiple readers and a single writer. You are asked to design a lock that lets multiple readers read at the same time, but only one writer writes at a time.
 </div>
</div>

<div>
 # Solution
 <div>
First of all, let us define the APIs our class will expose. We'll need two for writer and two for reader. These are: 

<ul>
 <li>acquireReadLock</li>
 <li>releaseReadLock</li>
 <li>acquireWriteLock</li>
 <li>releaseWriteLock</li>
</ul> 

This problem becomes simple if you think about each case:
 
<ol>
 <li>Before we allow a reader to enter the critical section, we need to make sure that there's no writer in progress. It is ok to have other readers in the critical section since they aren't making any modifications.</li>
 <li>Before we allow a writer to enter the critical section, we need to make sure that there's no reader or writer in the critical section.</li>
</ol>

Let's start with the reader use case. We can have multiple readers acquire the read lock and to keep track of all of them; we'll need a count. We increment this count whenever a reader acquires a read lock and decrement it whenever a reader releases it.

Releasing the read lock is easy, but before we acquire the read lock, we need to be sure that no other writer is currently writing. Again, we'll need some variable to keep track of whether a writer is writing. Since only a single writer can write at a given point in time, we can just keep a boolean variable to denote if the write lock is acquired or not.

Additionally, we'll also need a condition variable for the readers and writers to wait while the other party is in progress. We'll use the associated mutex lock with the condition variable to guard the sections of the code where we manipulate any shared variables. Let's translate what we have discussed so far into code.


```ruby
class ReadersWriteLock

 def initialize()
 @condVar = ConditionVariable.new
 @mutex = Mutex.new
 @writeInProgress = false
 @readers = 0
 end

 def acquireReadLock()
 end

 def releaseReadLock()
 end

 def acquireWriteLock()
 end

 def releaseWriteLock()
 end

end
```


Next we'll take a stab at the <code>acquireReadLock()</code> method.


```ruby
 def acquireReadLock()
 @mutex.lock()

 while @writeInProgress == true
 @condVar.wait(@mutex)
 end

 @readers += 1
 @mutex.unlock()
 end
```


Note that multiple reader threads can invoke the above method and not block if no write is in progress thus satisfying the condition that multiple readers can read at the same time. Next let's examine the <code>releaseReadLock()</code> method.


```ruby
 def releaseReadLock()
 @mutex.lock()
 @readers -= 1
 @condVar.broadcast()
 @mutex.unlock()
 end
```


When releasing the read lock, each reader decrements the <code>readers</code> count. Since multiple reader threads can modify the shared readers' count, we guard it with the mutex lock. Also, we notify any writer threads waiting on the condition variable. Note that a 
reader notifies the condition variable even if the readers' count is not zero. We can improve the code as follows, but the above implementation will also work.


```ruby
 def releaseReadLock()
 @mutex.lock()

 @readers -= 1

 if @readers == 0
 @condVar.broadcast()
 end
 @mutex.unlock()
 end
```


Now let's turn to the writer thread case. A writer should only proceed if no reader or writer is currently in progress, implying we need to check for two conditions. The implementation is as follows:

```ruby
 def acquireWriteLock()
 @mutex.lock()

 while @readers != 0 or @writeInProgress == true
 @condVar.wait(@mutex)
 end
 @writeInProgress = true

 @mutex.unlock()
 end
```


The last piece is the <code>releaseWriteLock()</code> which sets the <code>writeInProgress</code> to false and notifies any reader threads waiting on the condition variable.


```ruby
 def releaseWriteLock()
 @mutex.lock()

 @writeInProgress = false
 @condVar.broadcast()

 @mutex.unlock()
 end
```


The complete code appears below in the code widget.

​In this lesson, ​ we discuss a common interview question involving the synchronization of multiple reader threads and a single writer thread.

The Basics

API Overview

Brief Intro to Asynchronous Programming

Interview Practice Problems

Bonus Questions

Epilogue

ReadWrite Lock

Read Write Lock

Solution