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.

Practice

1. Why is concurrency important in Ruby programs?

easy

A. It allows the program to do multiple tasks at the same time, improving speed.

B. It makes the program use less memory.

C. It automatically fixes bugs in the code.

D. It changes the program's output format.

Solution

1. Step 1: Understand concurrency's purpose

   Concurrency lets a program handle multiple tasks simultaneously instead of one after another.

2. Step 2: Identify the benefit in Ruby

   This improves speed and responsiveness, especially when waiting for slow tasks or handling many users.

3. Final Answer:

   It allows the program to do multiple tasks at the same time, improving speed. -> Option A

4. Quick Check:

   Concurrency = multitasking speedup [OK]

Hint: Concurrency means doing many things at once [OK]

Common Mistakes:

• Thinking concurrency reduces memory usage
• Believing concurrency fixes bugs automatically
• Confusing concurrency with output formatting

2. Which of the following is the correct way to start a new thread in Ruby?

easy

A. Thread.new { puts 'Hello from thread' }

B. thread.start { puts 'Hello from thread' }

C. new Thread { puts 'Hello from thread' }

D. Thread.run { puts 'Hello from thread' }

Solution

1. Step 1: Recall Ruby thread syntax

   In Ruby, threads are created using Thread.new with a block of code.

2. Step 2: Check each option

   Only Thread.new { ... } is valid Ruby syntax to start a thread.

3. Final Answer:

   Thread.new { puts 'Hello from thread' } -> Option A

4. Quick Check:

   Thread.new starts threads [OK]

Hint: Use Thread.new with a block to start threads [OK]

Common Mistakes:

• Using incorrect method names like thread.start
• Trying Java-style thread creation syntax
• Confusing Thread.run with Thread.new

3. What will this Ruby code output?

thread = Thread.new { 5.times { |i| puts i; sleep 0.1 } }
thread.join
puts 'Done'

medium

A. Only 'Done' is printed

B. Done 0 1 2 3 4 (each number on its own line)

C. 0 1 2 3 4 Done (each number on its own line)

D. No output because of an error

Solution

1. Step 1: Understand thread execution

   The thread prints numbers 0 to 4 with a short pause between each.

2. Step 2: Effect of thread.join

   thread.join waits for the thread to finish before continuing to print 'Done'.

3. Final Answer:

   0 1 2 3 4 Done (each number on its own line) -> Option C

4. Quick Check:

   Thread prints numbers then main prints Done [OK]

Hint: thread.join waits for thread to finish before continuing [OK]

Common Mistakes:

• Thinking 'Done' prints before numbers
• Assuming no output due to thread
• Ignoring thread.join effect

4. What is wrong with this Ruby code that tries to use concurrency?

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

medium

A. The code will cause a syntax error.

B. The variable i is shared and may cause unexpected output.

C. threads.each(&:join) should be threads.join.

D. Thread.new is not the correct way to create threads.

Solution

1. Step 1: Analyze variable capture in threads

   The block uses variable i from the loop, which may change before thread runs, causing unexpected output.

2. Step 2: Identify concurrency issue

   Each thread may print the same or wrong i value because i is shared and changes quickly.

3. Final Answer:

   The variable i is shared and may cause unexpected output. -> Option B

4. Quick Check:

   Loop variable shared in threads causes bugs [OK]

Hint: Loop variables shared in threads cause unexpected values [OK]

Common Mistakes:

• Thinking Thread.new is wrong syntax
• Confusing threads.each(&:join) with threads.join
• Assuming syntax error without checking code

5. You want to speed up a Ruby program that downloads many files. Which concurrency approach is best and why?

hard

A. Use a single thread to download files one by one to avoid complexity.

B. Use threads but add sleep calls to slow down downloads.

C. Use multiple processes because Ruby threads cannot run in parallel at all.

D. Use threads to download files concurrently because IO waits can run in parallel.

Solution

1. Step 1: Understand IO-bound tasks and concurrency

   Downloading files is IO-bound and benefits from concurrency because waiting for network is slow.

2. Step 2: Choose concurrency method in Ruby

   Ruby threads can run IO tasks concurrently, improving speed without extra processes.

3. Final Answer:

   Use threads to download files concurrently because IO waits can run in parallel. -> Option D

4. Quick Check:

   Threads speed up IO waits in Ruby [OK]

Hint: Use threads for IO tasks to improve speed [OK]

Common Mistakes:

• Thinking Ruby threads never run in parallel
• Ignoring concurrency benefits for IO tasks
• Adding unnecessary sleep calls