GIL (Global Interpreter Lock) impact in Ruby - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Ruby threading code?

Consider the following Ruby code using threads. What will be printed?

Ruby

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

A 1000

B A number less than 5000

C 5000

D Raises a runtime error

💡 Hint

Think about how Ruby's GIL affects thread execution and shared variable updates.

Because of the GIL, threads do not run Ruby code truly in parallel. However, the increment operation is not atomic, so race conditions occur. This causes the final count to be less than 5000.

🧠 Conceptual

intermediate

Which statement best describes Ruby's GIL impact on CPU-bound threads?

Choose the statement that correctly describes how Ruby's GIL affects CPU-bound threads.

A Ruby's GIL prevents true parallel execution of CPU-bound threads, limiting them to one core at a time.

B Ruby's GIL allows multiple CPU-bound threads to run in parallel on multiple cores.

C Ruby's GIL only affects IO-bound threads, not CPU-bound threads.

D Ruby does not have a GIL, so threads run fully in parallel.

💡 Hint

Consider how the GIL serializes execution of Ruby code.

The GIL ensures only one thread executes Ruby code at a time, so CPU-bound threads cannot run in parallel on multiple cores.

🔧 Debug

advanced

Why does this Ruby code produce inconsistent results with threads?

Examine the code below. Why does the final printed value vary each run?

Ruby

total = 0
threads = []
10.times do
  threads << Thread.new do
    100.times { total += 1 }
  end
end
threads.each(&:join)
puts total

A Because the variable 'total' is not thread-safe and increments cause race conditions.

B Because the threads are not properly joined before printing.

C Because the GIL locks the variable 'total' preventing any increments.

D Because Ruby threads run in parallel on multiple cores causing synchronization issues.

💡 Hint

Think about what happens when multiple threads update the same variable without locks.

The increments on 'total' are not atomic, so race conditions cause inconsistent final values despite the GIL.

📝 Syntax

advanced

Which Ruby code snippet correctly creates threads that safely increment a shared counter?

Choose the code that safely increments a shared counter variable using threads in Ruby.

A

counter = 0
threads = []
3.times do
  threads << Thread.new do
    100.times do
      counter += 1
    end
  end
end
puts counter

B

counter = 0
mutex = Mutex.new
threads = []
3.times do
  threads << Thread.new do
    100.times do
      counter += 1
    end
  end
end
threads.each(&:join)
puts counter

C

counter = 0
threads = []
3.times do
  threads << Thread.new do
    100.times do
      mutex.synchronize { counter += 1 }
    end
  end
end
threads.each(&:join)
puts counter

D

counter = 0
mutex = Mutex.new
threads = []
3.times do
  threads << Thread.new do
    100.times do
      mutex.synchronize { counter += 1 }
    end
  end
end
threads.each(&:join)
puts counter

💡 Hint

Look for proper use of Mutex to avoid race conditions.

Option D uses a Mutex and synchronizes increments, preventing race conditions. Option D lacks synchronization. Option D uses mutex without defining it. Option D does not join threads before printing.

🚀 Application

expert

How can Ruby programs achieve true parallelism despite the GIL?

Which approach allows Ruby programs to perform true parallel execution despite the GIL?

A Using fibers to switch between tasks cooperatively.

B Using multiple Ruby threads to run CPU-bound tasks concurrently.

C Using multiple processes with inter-process communication instead of threads.

D Disabling the GIL in Ruby interpreter settings.

💡 Hint

Think about how to bypass the GIL's single-thread execution limitation.

Ruby's GIL limits threads to one core at a time. Using multiple processes allows true parallelism because each process has its own interpreter and memory space.

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