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="ans">
<p>A mistaken belief is that we only need to synchronize access to shared resources when writing to them and not when reading them. Consider the snippet below. We have an array of size two initialized with true values. The writer thread flips the boolean values in all the array elements in a loop. Since the array is shared, we guard the write to the array in a mutex synchronize block. We have another reader thread that outputs the array to the console. With proper synchronization, the output on the console will consist of either all true or all false values. Run the widget below and see what happens:</p>

</div>

mutex = Mutex.new
array = []

2.times do |i|
  array[i] = true
end


writer = Thread.new do

  while true
    mutex.synchronize {
      array.each_with_index do |el, i|
        array[i] = !array[i]
      end
    }
    # sleep(0.01)
  end
end


reader = Thread.new do

  while true
    puts array.to_s()
    sleep(0.1)
  end

end


sleep(5)

<div class="ans">
<p>You can observe from the output that the reader thread sees a partially updated array because it reads from the array without synchronization. The reason for this inconsistency is that the writer thread doesn't atomically update the array. It updates the array elements one by one and another thread can get scheduled whilst the writer is still updating the array. If the newly scheduled thread reads the array, it sees a partially updated structure. This is also referred to as reading a <b>torn value</b> in some multithreaded languages.</p>

<p>Contrast the above program with the one below. We update a variable <code class="mthd">item</code> with an integer value of 5 or 6 alternatively in a writer thread. A reader thread outputs the value of the variable in a loop. What would be the output of the code widget now? Will you see a torn value? What does a torn value even mean in the context of updating an integer?</p>

</div>

<div>
<p>A mistaken belief is that we only need to synchronize access to shared resources when writing to them and not when reading them. Consider the snippet below. We have an array of size two initialized with true values. The writer thread flips the boolean values in all the array elements in a loop. Since the array is shared, we guard the write to the array in a mutex synchronize block. We have another reader thread that outputs the array to the console. With proper synchronization, the output on the console will consist of either all true or all false values. Run the widget below and see what happens:</p>

</div>

<div>
<p>You can observe from the output that the reader thread sees a partially updated array because it reads from the array without synchronization. The reason for this inconsistency is that the writer thread doesn't atomically update the array. It updates the array elements one by one and another thread can get scheduled whilst the writer is still updating the array. If the newly scheduled thread reads the array, it sees a partially updated structure. This is also referred to as reading a <b>torn value</b> in some multithreaded languages.</p>

<p>Contrast the above program with the one below. We update a variable <code>item</code> with an integer value of 5 or 6 alternatively in a writer thread. A reader thread outputs the value of the variable in a loop. What would be the output of the code widget now? Will you see a torn value? What does a torn value even mean in the context of updating an integer?</p>

</div>

This lesson continues the discussion of Mutex in Ruby.

The Basics

API Overview

Brief Intro to Asynchronous Programming

Interview Practice Problems

Bonus Questions

Epilogue

...continued