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">
   # Implementing a Barrier
    <div class="ans">
<p>A barrier can be thought of as a point in the program code, which all or some of the threads need to reach before any one of them is allowed to proceed further.</p>
    </div>
</div>


<div class="card">
# Solution
<div class="ans">

<p>A barrier allows multiple threads to congregate at a point in code before any one of the thread is allowed to move forward. Python and most other languages provide libraries that make barrier construct available for developer use. Even though we are re-inventing the wheel but this makes for a good interview question.</p>

<p> We can immediately realize that our solution will need a count variable to track the number of threads that have arrived at the barrier. If we have <span class='i_b'>n</span> threads, then <span class='i_b'>n-1</span> threads must wait for the <b>nth</b> thread to arrive. This suggests we have the <b>n-1</b> threads execute the wait method and the <b>nth</b> thread wakes up all the asleep <b>n-1</b> threads.</p>

<p>Below is the code:</p>

</div>
</div>

class Barrier

    def initialize(totalThreads)
   	 @count = 0
   	 @totalThreads = totalThreads
   	 @mutex = Mutex.new
   	 @cv = ConditionVariable.new
    end

    def await
   	 @mutex.synchronize do
   		 # increment the counter whenever a thread arrives at the barrier
   		 @count = @count + 1

   		 # if you are the nth thread
   		 if (@count == @totalThreads)
   			 # wake up all the threads
   			 @cv.broadcast
   			 # remember to reset count so that barrier can be reused
   			 @count = 0
   		 else
   			 # wait if you aren't the nth thread
   			 @cv.wait(@mutex)
   		 end
   	 end
    end
end

<div class="ans">
<p>Notice how we are resetting the <code class="mthd">count</code> to zero on <b>line#20</b>. This is done so that we are able to re-use the barrier.</p>

<p>Below is the working code, along with a test case. The test-case creates three threads and has them synchronize on a barrier three times. We introduce sleeps accordingly so that, thread 1 reaches the barrier first, then thread 2 and finally thread 3. None of the threads is able to move forward until all the threads reach the barrier. This is verified by the order in which each thread prints itself in the output.</p>

## First Cut
<p>Here's the first stab at the problem:</p>

</div>


<div>
   # Implementing a Barrier
    <div>
<p>A barrier can be thought of as a point in the program code, which all or some of the threads need to reach before any one of them is allowed to proceed further.</p>
    </div>
</div>


<div>
# Solution
<div>

<p>A barrier allows multiple threads to congregate at a point in code before any one of the thread is allowed to move forward. Python and most other languages provide libraries that make barrier construct available for developer use. Even though we are re-inventing the wheel but this makes for a good interview question.</p>

<p> We can immediately realize that our solution will need a count variable to track the number of threads that have arrived at the barrier. If we have <span>n</span> threads, then <span>n-1</span> threads must wait for the <b>nth</b> thread to arrive. This suggests we have the <b>n-1</b> threads execute the wait method and the <b>nth</b> thread wakes up all the asleep <b>n-1</b> threads.</p>

<p>Below is the code:</p>

</div>
</div>

<div>
<p>Notice how we are resetting the <code>count</code> to zero on <b>line#20</b>. This is done so that we are able to re-use the barrier.</p>

<p>Below is the working code, along with a test case. The test-case creates three threads and has them synchronize on a barrier three times. We introduce sleeps accordingly so that, thread 1 reaches the barrier first, then thread 2 and finally thread 3. None of the threads is able to move forward until all the threads reach the barrier. This is verified by the order in which each thread prints itself in the output.</p>

## First Cut
<p>Here's the first stab at the problem:</p>

</div>

This lesson discusses how a barrier is implemented in Ruby.

The Basics

API Overview

Brief Intro to Asynchronous Programming

Interview Practice Problems

Bonus Questions

Epilogue

Implementing a Barrier

Implementing a Barrier

Solution