Thread creation and execution in Ruby - Deep Dive

Overview - Thread creation and execution

What is it?

Thread creation and execution in Ruby means starting small, separate paths of work inside a program that can run at the same time. Each thread can do its own job independently, like having multiple helpers working together. This helps programs do many things faster or handle waiting times better. Threads share the same space but run their tasks separately.

Why it matters

Without threads, programs would do one thing at a time, making them slow or unresponsive, especially when waiting for things like files or network data. Threads let programs handle multiple tasks at once, improving speed and user experience. For example, a web server can talk to many users at the same time using threads.

Where it fits

Before learning threads, you should understand basic Ruby programming, how code runs step-by-step, and simple methods. After threads, you can learn about thread safety, synchronization tools like Mutex, and advanced concurrency patterns.

Mental Model

Core Idea

Threads are like independent workers inside your program that run tasks at the same time but share the same workspace.

Think of it like...

Imagine a kitchen where several cooks (threads) prepare different dishes simultaneously, sharing the same kitchen tools and space but working on separate recipes.

Main Program
  │
  ├─ Thread 1: Task A
  ├─ Thread 2: Task B
  └─ Thread 3: Task C

All threads run alongside each other, sharing the same memory but doing different jobs.

Build-Up - 7 Steps

1

Foundation

Understanding what a thread is

Concept: Introduce the idea of a thread as a separate path of execution inside a program.

In Ruby, a thread is a way to run code independently from the main program flow. Think of it as a mini-program inside your program that can do work at the same time as others. You create a thread by telling Ruby what code to run in it.

Result

You know that threads let your program do multiple things at once instead of waiting for one task to finish before starting another.

Understanding threads as separate workers helps you see how programs can multitask and be more efficient.

2

Foundation

Creating a simple thread

Concept: Learn how to create a thread in Ruby using Thread.new and run code inside it.

You create a thread by calling Thread.new and passing a block of code. This block runs inside the new thread. For example: thread = Thread.new do puts "Hello from thread!" end thread.join # Waits for the thread to finish before continuing.

Result

The program prints "Hello from thread!" from the new thread, showing it ran separately.

Knowing how to start a thread is the first step to using concurrency in Ruby.

3

Intermediate

Running multiple threads together

🤔Before reading on: do you think threads run in the order they are created or can they finish in any order? Commit to your answer.

Concept: Learn that threads run independently and may finish in any order depending on timing.

You can create many threads to run different tasks: threads = [] 3.times do |i| threads << Thread.new do sleep(rand(0.1..0.5)) puts "Thread #{i} done" end end threads.each(&:join) Each thread sleeps a random time, so the order of finishing changes each run.

Result

The output shows threads finishing in different orders each time you run the program.

Understanding that thread execution order is unpredictable helps you write code that does not rely on a fixed order.

4

Intermediate

Using thread.join to wait for completion

🤔Before reading on: do you think the main program waits for threads automatically or do you need to tell it to wait? Commit to your answer.

Concept: Learn that the main program continues immediately unless you explicitly wait for threads using join.

When you create threads, the main program does not wait for them by default. You use thread.join to pause the main program until that thread finishes: thread = Thread.new { sleep(1); puts "Done" } puts "Before join" thread.join puts "After join" Without join, "After join" would print immediately.

Result

The output shows "Before join", then after 1 second "Done", then "After join".

Knowing when and how to wait for threads prevents your program from exiting too early or missing thread results.

5

Intermediate

Sharing data between threads safely

🤔Before reading on: do you think threads can change shared data without problems? Commit to your answer.

Concept: Introduce the problem of threads changing shared data at the same time causing errors.

Threads share the same memory, so if two threads change the same variable at once, it can cause wrong results. For example: count = 0 threads = 10.times.map do Thread.new { 1000.times { count += 1 } } end threads.each(&:join) puts count The result may be less than 10,000 because of conflicts.

Result

The printed count is often less than expected due to race conditions.

Understanding shared data risks is key to writing correct multithreaded programs.

6

Advanced

Using Mutex to prevent data conflicts

🤔Before reading on: do you think adding a lock around shared data changes fixes the problem? Commit to your answer.

Concept: Learn how to use Mutex to lock shared data so only one thread changes it at a time.

A Mutex is a lock that threads must get before changing shared data: mutex = Mutex.new count = 0 threads = 10.times.map do Thread.new do 1000.times do mutex.synchronize { count += 1 } end end end threads.each(&:join) puts count Now the count is always correct.

Result

The printed count is always 10,000, showing no conflicts.

Knowing how to use Mutex prevents subtle bugs and data corruption in threaded programs.

7

Expert

Understanding Ruby's Global Interpreter Lock (GIL)

🤔Before reading on: do you think Ruby threads run truly in parallel on multiple CPU cores? Commit to your answer.

Concept: Explain that Ruby MRI has a Global Interpreter Lock that allows only one thread to execute Ruby code at a time.

Ruby MRI uses a GIL to simplify thread safety inside the interpreter. This means even if you create many threads, only one thread runs Ruby code at once. Threads can still help with waiting tasks like IO, but CPU-heavy work won't speed up with threads alone. Other Ruby implementations like JRuby do not have this limitation.

Result

Threads improve IO concurrency but not CPU parallelism in Ruby MRI.

Understanding the GIL helps you choose the right concurrency tools and avoid expecting impossible speedups.

Under the Hood

When you create a thread in Ruby, the interpreter sets up a new execution context with its own call stack but shares the same memory space. The Ruby Virtual Machine schedules threads cooperatively, switching between them to give the illusion of simultaneous execution. However, Ruby MRI uses a Global Interpreter Lock (GIL) that allows only one thread to execute Ruby code at a time, preventing true parallel execution of Ruby code. Threads can still run native extensions or wait on IO in parallel.

Why designed this way?

The GIL was introduced to simplify memory management and avoid complex race conditions inside the Ruby interpreter. It trades off true parallelism for easier implementation and safer memory handling. Other Ruby implementations like JRuby or TruffleRuby use different approaches to allow real parallel threads but with more complexity.

┌─────────────────────────────┐
│        Main Program         │
│  Shared Memory & Variables  │
└─────────────┬───────────────┘
              │
  ┌───────────┴───────────┐
  │                       │
┌─▼─┐                   ┌─▼─┐
│T1 │                   │T2 │
│   │                   │   │
└───┘                   └───┘

Only one thread runs Ruby code at a time due to GIL,
but threads can switch quickly to simulate concurrency.

Myth Busters - 4 Common Misconceptions

Quick: do you think Ruby threads run on multiple CPU cores at the same time? Commit to yes or no before reading on.

Common Belief: Ruby threads run in parallel on multiple CPU cores, speeding up CPU-heavy tasks.

Reality: Ruby MRI threads are limited by the Global Interpreter Lock, so only one thread runs Ruby code at a time, preventing true parallel CPU execution.

Why it matters: Expecting CPU speedups from threads in Ruby MRI leads to wasted effort and confusion when performance does not improve.

Quick: do you think threads automatically protect shared data from conflicts? Commit to yes or no before reading on.

Common Belief: Threads automatically handle shared data safely without extra work.

Reality: Threads share memory but do not protect data automatically; you must use synchronization tools like Mutex to avoid race conditions.

Why it matters: Ignoring data safety causes bugs that are hard to find and fix, leading to incorrect program behavior.

Quick: do you think thread.join is optional and the program waits for threads by default? Commit to yes or no before reading on.

Common Belief: The main program waits for all threads to finish before exiting automatically.

Reality: The main program continues immediately unless you explicitly call join on threads to wait for them.

Why it matters: Not waiting for threads can cause the program to exit early, losing thread results or causing incomplete work.

Quick: do you think creating many threads always improves program speed? Commit to yes or no before reading on.

Common Belief: More threads always mean faster program execution.

Reality: Too many threads cause overhead and context switching, which can slow down the program or cause resource exhaustion.

Why it matters: Blindly adding threads can degrade performance and cause crashes, so thread count must be managed carefully.

Expert Zone

1

Ruby threads can run native extensions or blocking IO operations in parallel despite the GIL, allowing concurrency in those areas.

2

Mutex locks can cause deadlocks if not used carefully, especially when multiple locks are acquired in different orders.

3

Thread-local variables let you store data unique to each thread, avoiding shared data conflicts without locks.

When NOT to use

Use threads in Ruby MRI mainly for IO-bound tasks or concurrency with external resources. For CPU-bound parallelism, consider using processes (fork) or JRuby which supports true parallel threads without GIL.

Production Patterns

In real-world Ruby apps, threads are used in web servers like Puma to handle many requests concurrently. Mutexes protect shared caches or counters. Background jobs may use threads for parallel IO. Developers also combine threads with event-driven libraries for efficient concurrency.

Connections

Asynchronous programming

Alternative concurrency model

Understanding threads helps grasp why asynchronous callbacks or promises avoid some threading pitfalls by not using multiple threads.

Operating system processes

Related concurrency unit but heavier weight

Knowing threads share memory while processes have separate memory explains tradeoffs in speed and safety.

Human multitasking

Similar mental model of switching attention

Seeing threads like a person switching between tasks helps understand why too many threads cause overhead and inefficiency.

Common Pitfalls

#1 Not waiting for threads to finish before program exit

Wrong approach:

Thread.new { puts 'Hello' }
puts 'Done'

Correct approach:

thread = Thread.new { puts 'Hello' }
thread.join
puts 'Done'

Root cause:

Assuming threads run to completion automatically without explicit waiting.

#2 Modifying shared data without synchronization

Wrong approach:

count = 0
threads = 2.times.map { Thread.new { 1000.times { count += 1 } } }
threads.each(&:join)
puts count

Correct approach:

mutex = Mutex.new
count = 0
threads = 2.times.map do
Thread.new do
1000.times { mutex.synchronize { count += 1 } }
end
end
threads.each(&:join)
puts count

Root cause:

Not realizing that shared data access must be controlled to avoid race conditions.

#3 Creating too many threads causing slowdowns

Wrong approach:

10000.times { Thread.new { sleep(1) } }

Correct approach:

Use a thread pool or limit thread count to a reasonable number like 10-100 depending on resources.

Root cause:

Believing more threads always improve performance without considering system limits.

Key Takeaways

Threads in Ruby let your program do multiple tasks at the same time by running separate paths of code.

You create threads with Thread.new and must use thread.join to wait for them to finish.

Threads share memory, so you must protect shared data with Mutex to avoid errors.

Ruby MRI has a Global Interpreter Lock that prevents true parallel execution of Ruby code.

Threads are best for IO-bound tasks in Ruby; for CPU-bound work, consider other concurrency methods.