Why concurrency matters in Ruby - Challenge Your Understanding

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Ruby code using threads?

Consider this Ruby code that creates two threads incrementing a shared counter without synchronization. What will be the output?

Ruby

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

A 2000

B 1000

C A number less than 2000

D Raises a ThreadError

💡 Hint

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

Because the threads update counter without synchronization, some increments can be lost due to race conditions. So the final value is usually less than 2000.

🧠 Conceptual

intermediate

Why does Ruby MRI have a Global Interpreter Lock (GIL)?

Why does the standard Ruby interpreter (MRI) use a Global Interpreter Lock (GIL)?

A To prevent race conditions by allowing only one thread to execute Ruby code at a time

B To allow multiple threads to run Ruby code truly in parallel

C To speed up IO operations by running threads concurrently

D To enable garbage collection to run in parallel with Ruby code

💡 Hint

Think about how MRI manages thread safety internally.

The GIL ensures only one thread executes Ruby code at a time, preventing race conditions inside the interpreter but limiting true parallelism.

❓ Predict Output

advanced

What does this Ruby code output with concurrent fibers?

Given this Ruby code using fibers, what will be printed?

Ruby

fiber1 = Fiber.new do
  puts 'Fiber 1 start'
  Fiber.yield
  puts 'Fiber 1 resume'
end
fiber2 = Fiber.new do
  puts 'Fiber 2 start'
  Fiber.yield
  puts 'Fiber 2 resume'
end
fiber1.resume
fiber2.resume
fiber1.resume
fiber2.resume

A Fiber 1 start\nFiber 2 start\nFiber 1 resume

B Fiber 1 start\nFiber 1 resume\nFiber 2 start\nFiber 2 resume

C Fiber 1 start\nFiber 2 start\nFiber 2 resume\nFiber 1 resume

D Fiber 1 start\nFiber 2 start\nFiber 1 resume\nFiber 2 resume

💡 Hint

Remember that Fiber.yield pauses the fiber and resume continues it.

The fibers start and yield in order, then resume in the same order, producing the output in option D.

🔧 Debug

advanced

Why does this Ruby thread code raise an error?

Look at this Ruby code snippet. Why does it raise a ThreadError?

Ruby

thread = Thread.new do
  sleep 1
end
thread.run
thread.run

A Because the thread is already running and <code>run</code> is called again causing a deadlock

B Because <code>Thread#run</code> cannot be called twice on the same thread

C Because <code>Thread#run</code> is deprecated and raises an error

D Because <code>Thread#run</code> can only be called from the main thread

💡 Hint

Check Ruby docs for Thread#run behavior.

Calling Thread#run twice on the same thread raises ThreadError because the thread cannot be restarted while running.

🚀 Application

expert

How to safely increment a shared counter in Ruby threads?

You want to increment a shared counter from multiple Ruby threads safely. Which code snippet correctly uses synchronization to avoid race conditions?

A

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

B

counter = 0
threads = 2.times.map do
  Thread.new do
    1000.times do
      counter += 1
    end
  end
end
threads.each(&:join)
puts counter

C

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

D

counter = 0
threads = 2.times.map do
  Thread.new do
    1000.times do
      Thread.pass
      counter += 1
    end
  end
end
threads.each(&:join)
puts counter

💡 Hint

Think about locking only the increment operation, not the whole loop.

Option A locks each increment individually, preventing race conditions while allowing concurrency. Option A locks the entire 1000 increments per thread, serializing the work unnecessarily. Options A and B do not use synchronization and risk race conditions.