Concurrency in Ruby: Introduction to Multithreading

What is Concurrency?
What is Multithreading?
Ruby and the Global Interpreter Lock (GIL)
Creating and Managing Threads in Ruby
Thread Safety: Avoiding Race Conditions
- What is a Race Condition?
- Using Mutexes for Synchronization
Common Pitfalls in Ruby Multithreading
- The GIL’s Impact on CPU-Bound Tasks
- Deadlocks
Practical Use Cases for Multithreading in Ruby
Conclusion
References

1. What is Concurrency?

Concurrency is the ability of a system to handle multiple independent tasks overlapping in time. Unlike parallelism (which requires multiple CPU cores to execute tasks simultaneously), concurrency focuses on task scheduling—allowing tasks to start, run, and complete in an interleaved fashion.

For example, imagine a chef cooking breakfast: they might start frying eggs (task 1), then start brewing coffee (task 2) while the eggs cook, and finally toast bread (task 3) while the coffee brews. The tasks aren’t executed at the same time, but they overlap, reducing the total time to make breakfast.

In software, concurrency improves responsiveness and resource utilization. For Ruby developers, concurrency is critical for building scalable applications (e.g., web servers, background job processors).

2. What is Multithreading?

Multithreading is a concurrency model where a single process spawns multiple threads—lightweight units of execution that share the same memory space. Threads are managed by the operating system (or runtime) and can run concurrently, interleaving their execution.

Key Characteristics of Threads:

Shared Memory: Threads within a process share the same heap, making it easy to share data (but also risky if not managed carefully).
Lightweight: Threads have lower overhead than processes (no separate memory space), so spawning many threads is feasible.
Interleaved Execution: The OS scheduler decides when to pause and resume threads, leading to interleaved execution (even on a single CPU core).

3. Ruby and the Global Interpreter Lock (GIL)

Ruby’s approach to multithreading is heavily influenced by the Global Interpreter Lock (GIL), a mutex (mutual exclusion lock) in the MRI (Matz’s Ruby Interpreter—the most common Ruby implementation) that ensures only one thread executes Ruby bytecode at a time.

Why the GIL Exists:

The GIL simplifies memory management in Ruby by preventing race conditions in the interpreter’s internal data structures (e.g., garbage collection metadata). However, it has a critical implication:

In MRI, multithreading does not enable true parallelism for CPU-bound tasks. Even with multiple threads, only one can execute Ruby code at a time.

When Does the GIL Release?

The GIL is released in two key scenarios:

I/O Operations: When a thread performs I/O (e.g., reading a file, making an HTTP request, waiting for a database query), the GIL is released, allowing other threads to run.
Sleep/Blocking Calls: Threads sleeping (sleep), waiting on a mutex, or blocked on external resources (e.g., network) release the GIL.

This makes multithreading in MRI ideal for I/O-bound tasks (e.g., web requests, file processing) but less useful for CPU-bound tasks (e.g., heavy computations).

Note: Other Ruby implementations like JRuby (Java-based) and Rubinius (LLVM-based) do not have a GIL, enabling true parallelism for CPU-bound tasks. For most developers, however, MRI is the default, so we’ll focus on it here.

4. Creating and Managing Threads in Ruby

Ruby’s Thread class provides a simple API for creating and managing threads. Let’s explore the basics.

4.1 Basic Thread Creation

To create a thread, use Thread.new with a block containing the code to execute:

# Create a simple thread
thread = Thread.new do
  puts "Hello from thread #{Thread.current.object_id}!"
  sleep 1 # Simulate work
  puts "Thread #{Thread.current.object_id} done!"
end

puts "Hello from the main thread!"

Output (order may vary due to interleaved execution):

Hello from the main thread!
Hello from thread 70160343452440!
Thread 70160343452440 done!

Thread.current returns the currently executing thread.
Threads run asynchronously by default: the main thread (the thread that starts your program) will continue executing while the new thread runs.

4.2 Joining Threads

By default, the main thread exits when it finishes executing, even if child threads are still running. To wait for a thread to finish, use Thread#join:

thread = Thread.new do
  sleep 2
  puts "Thread work done!"
end

puts "Main thread waiting..."
thread.join # Wait for the thread to finish
puts "Main thread exiting."

Output:

Main thread waiting...
Thread work done!
Main thread exiting.

You can also join multiple threads:

threads = 3.times.map do |i|
  Thread.new(i) do |thread_id| # Pass arguments to the thread
    sleep rand(1..3) # Simulate variable work time
    puts "Thread #{thread_id} finished!"
  end
end

threads.each(&:join) # Wait for all threads to finish
puts "All threads done!"

Output (order may vary):

Thread 1 finished!
Thread 0 finished!
Thread 2 finished!
All threads done!

4.3 Thread States and Lifecycle

Threads have a lifecycle with distinct states. Use Thread#status or Thread#alive? to check a thread’s state:

:run/true: The thread is executing.
:sleep: The thread is sleeping.
:aborting: The thread is being aborted.
false: The thread has finished (successfully or with an error).

Example:

thread = Thread.new do
  sleep 2
  puts "Thread done!"
end

puts "Status: #{thread.status}" # :sleep
thread.join
puts "Status after join: #{thread.status}" # false
puts "Alive? #{thread.alive?}" # false

Output:

Status: sleep
Thread done!
Status after join: false
Alive? false

4.4 Thread Exceptions

If a thread raises an unhandled exception, it dies silently by default. To handle exceptions, use Thread#join with a block, or rescue within the thread:

thread = Thread.new do
  raise "Oops! Something went wrong."
end

begin
  thread.join
rescue => e
  puts "Caught exception: #{e.message}" # Caught exception: Oops! Something went wrong.
end

5. Thread Safety: Avoiding Race Conditions

When threads share data, they risk race conditions—situations where the outcome depends on the interleaving of thread execution. Let’s see why this happens and how to fix it.

5.1 What is a Race Condition?

Consider a shared counter incremented by multiple threads:

counter = 0
threads = 10.times.map do
  Thread.new do
    1000.times { counter += 1 } # Increment counter 1000 times per thread
  end
end

threads.each(&:join)
puts "Final counter: #{counter}" # Expected: 10,000. Actual: Often less!

Why? The operation counter += 1 is not atomic (indivisible). It breaks down into three steps:

Read the current value of counter.
Increment the value.
Write the new value back.

If two threads interleave these steps, they may overwrite each other’s updates:

Thread A reads counter = 500.
Thread B reads counter = 500.
Thread A increments to 501 and writes back.
Thread B increments to 501 and writes back.
Result: counter increases by 1 instead of 2.

5.2 Using Mutexes for Synchronization

A mutex (mutual exclusion lock) ensures only one thread can access a critical section of code at a time. Ruby’s Mutex class provides this functionality.

To fix the race condition, wrap the shared data access in a mutex:

require 'thread'

counter = 0
mutex = Mutex.new # Create a mutex

threads = 10.times.map do
  Thread.new do
    1000.times do
      mutex.synchronize do # Only one thread enters this block at a time
        counter += 1
      end
    end
  end
end

threads.each(&:join)
puts "Final counter: #{counter}" # 10000 (correct!)

Mutex#synchronize locks the mutex when entering the block and releases it when exiting (even if an exception is raised), ensuring thread safety.

5.3 Other Synchronization Tools

Ruby provides additional tools for thread safety:

Condition Variables: ConditionVariable lets threads wait for a signal (e.g., “data is ready”) before proceeding.
Semaphores: Thread::Semaphore limits the number of threads that can access a resource (e.g., “only 5 threads can use the database connection pool”).

6. Common Pitfalls in Ruby Multithreading

Multithreading is powerful but error-prone. Here are key pitfalls to avoid.

6.1 The GIL’s Impact on CPU-Bound Tasks

As discussed earlier, MRI’s GIL prevents parallel execution of Ruby code. For CPU-bound tasks (e.g., calculating prime numbers), multithreading may not speed up execution and could even add overhead due to thread switching.

Example: A CPU-bound task with threads vs. sequential execution:

# CPU-bound task: Calculate sum of squares
def sum_of_squares(n)
  (1..n).sum { |x| x ** 2 }
end

# Sequential
start = Time.now
2.times { sum_of_squares(1_000_000) }
puts "Sequential time: #{Time.now - start}" # ~0.2s

# Multithreaded (MRI)
start = Time.now
threads = 2.times.map { Thread.new { sum_of_squares(1_000_000) } }
threads.each(&:join)
puts "Multithreaded time: #{Time.now - start}" # ~0.2s (no speedup!)

Why? The GIL ensures only one thread runs Ruby code at a time, so the total work is the same.

6.2 Deadlocks

A deadlock occurs when two or more threads wait indefinitely for locks held by each other.

Example: Two threads, two mutexes, and reversed locking order:

mutex_a = Mutex.new
mutex_b = Mutex.new

thread1 = Thread.new do
  mutex_a.synchronize do
    puts "Thread 1: Locked A. Waiting for B..."
    mutex_b.synchronize do # Blocks indefinitely (Thread 2 holds B)
      puts "Thread 1: Locked B!"
    end
  end
end

thread2 = Thread.new do
  mutex_b.synchronize do
    puts "Thread 2: Locked B. Waiting for A..."
    mutex_a.synchronize do # Blocks indefinitely (Thread 1 holds A)
      puts "Thread 2: Locked A!"
    end
  end
end

thread1.join
thread2.join

Output (program hangs):

Thread 1: Locked A. Waiting for B...
Thread 2: Locked B. Waiting for A...

Fix: Always acquire locks in a consistent order (e.g., always lock mutex_a before mutex_b).

6.3 Starvation

Starvation happens when a thread is indefinitely denied access to a resource (e.g., a low-priority thread never gets the mutex because higher-priority threads keep taking it). Mitigate this by keeping critical sections short and avoiding long-held locks.

7. Practical Use Cases for Multithreading in Ruby

Despite the GIL, multithreading is invaluable for I/O-bound tasks. Here are common use cases:

7.1 Web Servers

Web servers like Puma and Thin use threads to handle multiple HTTP requests concurrently. When a request waits for I/O (e.g., a database query), the GIL is released, allowing other requests to process.

7.2 Background Job Processing

Tools like Sidekiq (a popular Ruby background job processor) use threads to process multiple jobs concurrently. Jobs often involve I/O (e.g., sending emails, fetching data), making threads ideal.

7.3 Web Scraping

Scrapers fetching data from multiple URLs can use threads to parallelize HTTP requests, drastically reducing total runtime.

Example: Fetching multiple URLs with threads:

require 'net/http'
require 'uri'

urls = [
  'https://example.com',
  'https://github.com',
  'https://ruby-lang.org'
]

threads = urls.map do |url|
  Thread.new(url) do |u|
    uri = URI.parse(u)
    response = Net::HTTP.get_response(uri)
    puts "#{u}: #{response.code}"
  end
end

threads.each(&:join)