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">
# Spurious Wakeups
Condition variables suffer from spurious wakeups - that is, wakeup of threads waiting on the condition variable without being signaled. This is specifically allowed by the POSIX standard because it allows more efficient implementations of condition variables under some circumstances. Even though the official documentation doesn't mention this peculiarity, it is a common pattern across all programming languages including Python, Java, etc.

# Idiomatic Usage
The idiomatic usage of condition variables when waiting is as follows:
## Waiting on Condition Variable

```ruby
mutex.lock()

while predicate

 cv.wait() 

end

mutex.unlock()
```
The while loop ensures that if a thread experiences a spurious wakeup it goes back to waiting since the predicate or the condition for the while loop hasn't changed.

A newbie mistake is to use an if-condition instead of a while loop shown as follows:
## Incorrect Waiting on Condition Variable

```ruby
mutex.lock()

# NEVER DO THIS !!!
if predicate

 cv.wait() 

end

mutex.unlock()
```
For one, using the above incorrect pattern doesn't protect against spurious wakeups. Second, another thread can change the predicate in the time between the condition variable is signaled and a waiting thread is woken up. If the waking thread doesn't recheck the predicate after waking up, it might end up proceeding forward with the predicate being false.

Similarly, when invoking <code class="mthd">signal()</code> or <code class="mthd">broadcast()</code> the idiomatic usage requires us to wrap the call in a mutex synchronization block. This should be the same mutex that is passed into the corresponding <code class="mthd">wait()</code> call.

```ruby
mutex.lock()
cv.signal() 
mutex.unlock()
```
Note that failing to follow the above pattern will not result in an exception but the resulting code will not be thread-safe.

# Ping Pong Example

Let's rewrite the ping pong example for two threads using condition variables. The predicate, in this case, would be the boolean <code class="mthd">flag</code> variable, which is set to true when it's ping thread's turn to print and false when it's pong thread's turn to print.

Note that we always mutate and read the boolean <code class="mthd">flag</code> while holding the mutex lock. This is important because we don't want to have a thread read the flag value and make a decision to move forward whilst it might get mutated by the other thread. 

</div>

<div>
# Spurious Wakeups
Condition variables suffer from spurious wakeups - that is, wakeup of threads waiting on the condition variable without being signaled. This is specifically allowed by the POSIX standard because it allows more efficient implementations of condition variables under some circumstances. Even though the official documentation doesn't mention this peculiarity, it is a common pattern across all programming languages including Python, Java, etc.

# Idiomatic Usage
The idiomatic usage of condition variables when waiting is as follows:
## Waiting on Condition Variable

```ruby
mutex.lock()

while predicate

 cv.wait() 

end

mutex.unlock()
```
The while loop ensures that if a thread experiences a spurious wakeup it goes back to waiting since the predicate or the condition for the while loop hasn't changed.

A newbie mistake is to use an if-condition instead of a while loop shown as follows:
## Incorrect Waiting on Condition Variable

```ruby
mutex.lock()

# NEVER DO THIS !!!
if predicate

 cv.wait() 

end

mutex.unlock()
```
For one, using the above incorrect pattern doesn't protect against spurious wakeups. Second, another thread can change the predicate in the time between the condition variable is signaled and a waiting thread is woken up. If the waking thread doesn't recheck the predicate after waking up, it might end up proceeding forward with the predicate being false.

Similarly, when invoking <code>signal()</code> or <code>broadcast()</code> the idiomatic usage requires us to wrap the call in a mutex synchronization block. This should be the same mutex that is passed into the corresponding <code>wait()</code> call.

```ruby
mutex.lock()
cv.signal() 
mutex.unlock()
```
Note that failing to follow the above pattern will not result in an exception but the resulting code will not be thread-safe.

# Ping Pong Example

Let's rewrite the ping pong example for two threads using condition variables. The predicate, in this case, would be the boolean <code>flag</code> variable, which is set to true when it's ping thread's turn to print and false when it's pong thread's turn to print.

Note that we always mutate and read the boolean <code>flag</code> while holding the mutex lock. This is important because we don't want to have a thread read the flag value and make a decision to move forward whilst it might get mutated by the other thread. 

</div>

This lesson continues the discussion on the use of condition variables in Ruby.

The Basics

API Overview

Brief Intro to Asynchronous Programming

Interview Practice Problems

Bonus Questions

Epilogue

... continued

Spurious Wakeups