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">
 # Introduction 
 <div class="ans">
Concurrency can be defined as dealing with multiple things at once. You can concurrently run several processes or threads on a machine with a single CPU but you'll not be parallel when doing so. Concurrency allows us to create an illusion of parallel execution even though the single CPU machine runs one thread or process at a time.

Parallelism is when we execute multiple things at once. True parallelism can only be achieved with multiple CPUs.

A machine with four cores and running one hundred processes is both parallel and concurrent but mostly concurrent because it can only do four things at a time.

Another paradigm to achieve concurrency on a single core-machine is via cooperative multitasking, which we discuss next.

## Cooperative Multitasking

Multithreading on a single core machine achieves concurrency by context switching threads for CPU time. Threads can be taken off of the CPU if they engage in an I/O call or exhaust their time slice. The OS preempts a thread forcing it to give up the use of the CPU. Cooperative Multitasking, on the other hand, takes a different approach in which the running process voluntarily gives up the CPU to other processes. A process may do so when it is logically blocked, say while waiting for user input or when it has initiated a network request and will be idle for a while.

The process scheduler relies on the processes to cooperate amongst themselves while using the CPU and is the reason why this paradigm of multitasking is called cooperative multitasking or non-preemptive multitasking. 

Fibers in Ruby enable cooperative multitasking. The onus of scheduling tasks reliably for CPU time falls on the programmer. A misbehaving task can hog the CPU without giving other tasks a chance to execute and cause starvation.

A Ruby fiber comes with its stack and can be paused and resumed again. It is conceptually similar to a coroutine. Let's disambiguate fibers and related concepts first.

## Coroutine
A coroutine is a general programming concept also found in various programming languages. A coroutine can be defined as a special function that can give up control to its caller without losing its state. The methods or functions that we are used to, the ones that conclusively return a value and don't remember state between invocations, can be thought of as a specialization of a coroutine, also known as subroutines.

Some languagues such as Python also have a related concept called generators which are essentially iterators and a subset of coroutines.

## Fiber
Fibers are essentially the same concept as coroutines. Python, for instance, has coroutines which behave similar to Ruby fibers. <a href="https://en.wikipedia.org/wiki/Fiber_(computer_science)" target="_blank">Wikipedia</a> says the only difference between them is fibers are a system level construct whereas coroutines are a language level construct. Coroutines may be thought of as implementation of fibers. From a practical standpoint, there is no difference when writing a coroutine or a fiber.

Note that another benefit of fibers is that they are lightweight in comparison to threads and don't suffer from thread-safety issues. We don't have to use any expensive locking or
synchronization when working with fibers.

As an example, we can rewrite our ping-pong example from the threading lessons using fibers. For now, don't fret about the syntax and note that we don't have any synchronization code in our solution below.

</div>
</div>

<div>
 # Introduction 
 <div>
Concurrency can be defined as dealing with multiple things at once. You can concurrently run several processes or threads on a machine with a single CPU but you'll not be parallel when doing so. Concurrency allows us to create an illusion of parallel execution even though the single CPU machine runs one thread or process at a time.

Parallelism is when we execute multiple things at once. True parallelism can only be achieved with multiple CPUs.

A machine with four cores and running one hundred processes is both parallel and concurrent but mostly concurrent because it can only do four things at a time.

Another paradigm to achieve concurrency on a single core-machine is via cooperative multitasking, which we discuss next.

## Cooperative Multitasking

Multithreading on a single core machine achieves concurrency by context switching threads for CPU time. Threads can be taken off of the CPU if they engage in an I/O call or exhaust their time slice. The OS preempts a thread forcing it to give up the use of the CPU. Cooperative Multitasking, on the other hand, takes a different approach in which the running process voluntarily gives up the CPU to other processes. A process may do so when it is logically blocked, say while waiting for user input or when it has initiated a network request and will be idle for a while.

The process scheduler relies on the processes to cooperate amongst themselves while using the CPU and is the reason why this paradigm of multitasking is called cooperative multitasking or non-preemptive multitasking. 

Fibers in Ruby enable cooperative multitasking. The onus of scheduling tasks reliably for CPU time falls on the programmer. A misbehaving task can hog the CPU without giving other tasks a chance to execute and cause starvation.

A Ruby fiber comes with its stack and can be paused and resumed again. It is conceptually similar to a coroutine. Let's disambiguate fibers and related concepts first.

## Coroutine
A coroutine is a general programming concept also found in various programming languages. A coroutine can be defined as a special function that can give up control to its caller without losing its state. The methods or functions that we are used to, the ones that conclusively return a value and don't remember state between invocations, can be thought of as a specialization of a coroutine, also known as subroutines.

Some languagues such as Python also have a related concept called generators which are essentially iterators and a subset of coroutines.

## Fiber
Fibers are essentially the same concept as coroutines. Python, for instance, has coroutines which behave similar to Ruby fibers. <a href="https://en.wikipedia.org/wiki/Fiber_(computer_science)" target="_blank">Wikipedia</a> says the only difference between them is fibers are a system level construct whereas coroutines are a language level construct. Coroutines may be thought of as implementation of fibers. From a practical standpoint, there is no difference when writing a coroutine or a fiber.

Note that another benefit of fibers is that they are lightweight in comparison to threads and don't suffer from thread-safety issues. We don't have to use any expensive locking or
synchronization when working with fibers.

As an example, we can rewrite our ping-pong example from the threading lessons using fibers. For now, don't fret about the syntax and note that we don't have any synchronization code in our solution below.

</div>
</div>

This lesson introduces the concept of asynchronous programming as an important programming paradigm.

The Basics

API Overview

Brief Intro to Asynchronous Programming

Interview Practice Problems

Bonus Questions

Epilogue

Introduction

Introduction

Cooperative Multitasking