GIL (Global Interpreter Lock) impact in Ruby

Introduction

The Global Interpreter Lock (GIL) is a mechanism that makes sure only one thread runs Ruby code at a time. This helps avoid problems but can slow down programs that try to do many things at once.

When you want to run multiple tasks at the same time in Ruby using threads.

When you notice your Ruby program is not getting faster even with multiple CPU cores.

When you want to understand why some Ruby programs don't speed up with threads.

When you plan to use Ruby threads for tasks like web servers or background jobs.

When you want to decide between using threads or processes in Ruby.

Syntax

Ruby

# Ruby threads example
thread = Thread.new do
  # code to run in new thread
end
thread.join

Ruby threads run inside the same process but the GIL allows only one thread to execute Ruby code at a time.

This means threads can help with waiting tasks but not with heavy CPU work.

Examples

This example runs two threads that print messages. They run one at a time because of the GIL, but switching happens fast.

Ruby

thread1 = Thread.new { 5.times { puts "Thread 1 working"; sleep 0.1 } }
thread2 = Thread.new { 5.times { puts "Thread 2 working"; sleep 0.1 } }
thread1.join
thread2.join

This example shows that using threads for heavy math doesn't speed up much because of the GIL.

Ruby

require 'benchmark'

result = Benchmark.measure do
  threads = 4.times.map do
    Thread.new do
      sum = 0
      10_000_000.times { sum += 1 }
    end
  end
  threads.each(&:join)
end

puts "Time taken: #{result.real} seconds"

Sample Program

This program creates two threads that print counts with pauses. Because of the GIL, only one thread runs Ruby code at a time, but they switch quickly, so output is mixed.

Ruby

thread1 = Thread.new do
  3.times do |i|
    puts "Thread 1: Count #{i + 1}"
    sleep 0.2
  end
end

thread2 = Thread.new do
  3.times do |i|
    puts "Thread 2: Count #{i + 1}"
    sleep 0.2
  end
end

thread1.join
thread2.join

Important Notes

The GIL prevents true parallel execution of Ruby code in threads.

Threads are still useful for tasks that wait for input/output, like reading files or network calls.

For CPU-heavy tasks, using multiple Ruby processes or other tools can help use multiple CPU cores.

Summary

The GIL lets only one Ruby thread run code at a time.

This can slow down programs that try to do many CPU tasks at once with threads.

Threads are still good for tasks that wait, like network or file operations.

Practice

1.

What does the Global Interpreter Lock (GIL) in Ruby do?

easy

A. Automatically speeds up all multi-threaded Ruby programs

B. Allows multiple threads to run Ruby code simultaneously

C. Prevents any threads from running in Ruby

D. Allows only one thread to execute Ruby code at a time

Solution

1. Step 1: Understand the role of GIL

   The GIL is a lock that ensures only one thread runs Ruby code at once.

2. Final Answer:

   Allows only one thread to execute Ruby code at a time -> Option D

3. Quick Check:

   GIL = single-thread execution [OK]

Hint: GIL means one thread runs Ruby code at a time [OK]

Common Mistakes:

• Thinking GIL allows true parallel Ruby code execution
• Believing GIL stops all threading
• Assuming GIL speeds up multi-threading

2.

Which Ruby code snippet correctly starts two threads that print numbers?

Option A:
threads = [Thread.new { puts 1 }, Thread.new { puts 2 }]
threads.each(&:join)

Option B:
Thread.new { puts 1 }
Thread.new { puts 2 }

Option C:
threads = Thread.new { puts 1 }
threads = Thread.new { puts 2 }
threads.join

Option D:
Thread.start { puts 1 }
Thread.start { puts 2 }

easy

A. Creates two threads and waits for both to finish

B. Creates two threads but does not wait for them

C. Creates one thread twice, only waits for last

D. Uses undefined Thread.start method

Solution

1. Step 1: Analyze thread creation and joining

   Creates two threads and waits for both to finish. Creates two threads and calls join on both, ensuring both finish.

2. Final Answer:

   Creates two threads and waits for both to finish -> Option A

3. Quick Check:

   Thread.new + join = wait for threads [OK]

Hint: Use join to wait for all threads to finish [OK]

Common Mistakes:

• Not calling join and missing thread completion
• Overwriting thread variables losing references
• Using non-existent Thread.start method

3.

What will be the output of this Ruby code considering the GIL?

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

medium

A. 5000

B. 1000

C. May be less than 5000 due to race conditions

D. 0

Solution

1. Step 1: Understand thread increments with GIL

   GIL allows one thread at a time, but count += 1 is not atomic and can cause race conditions.

2. Final Answer:

   May be less than 5000 due to race conditions -> Option C

3. Quick Check:

   Non-atomic increments + threads = race condition [OK]

Hint: GIL doesn't prevent race conditions on shared data [OK]

Common Mistakes:

• Assuming GIL makes increments atomic
• Expecting exact 5000 without synchronization
• Ignoring thread interference on variables

4.

Identify the problem in this Ruby code using threads and fix it:

count = 0
threads = 3.times.map do
  Thread.new do
    100.times { count += 1 }
  end
end
threads.each(&:join)
puts count

medium

A. Add a Mutex to synchronize increments

B. Remove threads and run increments sequentially

C. Use Thread.kill to stop threads early

D. No problem, code is correct

Solution

1. Step 1: Identify race condition on count variable

   Multiple threads increment count without synchronization causing race conditions.

2. Final Answer:

   Add a Mutex to synchronize increments -> Option A

3. Quick Check:

   Mutex prevents race conditions [OK]

Hint: Use Mutex to protect shared data in threads [OK]

Common Mistakes:

• Ignoring race conditions on shared variables
• Trying to kill threads instead of synchronizing
• Assuming GIL handles all thread safety

5.

You want to speed up a CPU-heavy Ruby program using threads. Considering the GIL, what is the best approach?

hard

A. Disable the GIL in Ruby settings

B. Use multiple processes instead of threads

C. Use threads only for I/O tasks, not CPU tasks

D. Use more threads since GIL allows parallel CPU work

Solution

1. Step 1: Understand GIL impact on CPU-bound threads

   GIL allows only one thread to run Ruby code at a time, so threads don't speed up CPU-heavy tasks.

2. Final Answer:

   Use multiple processes instead of threads -> Option B

3. Quick Check:

   Processes bypass GIL for CPU parallelism [OK]

Hint: Use processes, not threads, for CPU speedup in Ruby [OK]

Common Mistakes:

• Believing threads run CPU tasks in parallel with GIL
• Trying to disable GIL (not possible in standard Ruby)
• Using threads for CPU tasks instead of I/O