Thread safety concepts in Ruby - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to create a new thread in Ruby.

Ruby

thread = Thread.[1] do
  puts 'Hello from thread'
end
thread.join

Drag options to blanks, or click blank then click option'

Astart

Bnew

Ccreate

Drun

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'start' instead of 'new' to create a thread.

Using 'create' or 'run' which are not valid Thread methods.

In Ruby, Thread.new is used to create a new thread.

2fill in blank

medium

Complete the code to safely increment a shared counter using a Mutex.

Ruby

mutex = Mutex.new
counter = 0

mutex.[1] do
  counter += 1
end

Drag options to blanks, or click blank then click option'

Await

Bacquire

Clock

Dsynchronize

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'lock' without unlocking the mutex.

Using 'acquire' or 'wait' which are not Ruby Mutex methods.

The synchronize method locks the mutex, runs the block, then unlocks it.

3fill in blank

hard

Fix the error in the code to avoid race conditions when updating the shared variable.

Ruby

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

Drag options to blanks, or click blank then click option'

Amutex

Bcount

Cself

DThread

Attempts:

3 left

💡 Hint

Common Mistakes

Trying to synchronize on the shared variable itself.

Using Thread or self which do not provide locking.

You must use a Mutex object to synchronize access to shared data.

4fill in blank

hard

Fill both blanks to create a thread-safe hash using a Mutex.

Ruby

mutex = Mutex.new
safe_hash = {}

threads = 3.times.map do
  Thread.new do
    mutex.[1] do
      safe_hash[[2]] = 'value'
    end
  end
end
threads.each(&:join)

Drag options to blanks, or click blank then click option'

Asynchronize

Bkey

C:key

Dlock

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'lock' instead of 'synchronize' for mutex.

Using a variable 'key' without defining it.

Use synchronize to lock the mutex and :key as a symbol key for the hash.

5fill in blank

hard

Fill all three blanks to safely update a shared array in multiple threads.

Ruby

mutex = Mutex.new
shared_array = []
threads = []

5.times do |i|
  threads << Thread.new do
    mutex.[1] do
      shared_array.[2](i)
    end
  end
end
threads.each(&:join)

puts shared_array.[3]

Drag options to blanks, or click blank then click option'

Asynchronize

Bpush

Csort

Dlock

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'lock' instead of 'synchronize' for mutex.

Using 'append' instead of 'push' for arrays.

Not sorting the array before printing.

Use synchronize to lock the mutex, push to add elements, and sort to display sorted results.

Practice

1. What is the main purpose of thread safety in Ruby programs?

easy

A. To make the program run slower

B. To prevent errors when multiple threads access shared data

C. To allow threads to run without any synchronization

D. To avoid using threads altogether

Solution

1. Step 1: Understand thread safety concept

   Thread safety means making sure multiple threads do not cause errors when they access the same data.

2. Step 2: Identify the main goal

   The main goal is to prevent errors and data corruption when threads run at the same time.

3. Final Answer:

   To prevent errors when multiple threads access shared data -> Option B

4. Quick Check:

   Thread safety = prevent errors [OK]

Hint: Thread safety means safe shared data access [OK]

Common Mistakes:

• Thinking thread safety slows down programs
• Believing threads never need synchronization
• Confusing thread safety with avoiding threads

2. Which Ruby code snippet correctly uses a Mutex to protect a shared variable counter?

easy

A. mutex.synchronize { counter += 1 }

B. mutex.lock { counter += 1 }

C. mutex.unlock { counter += 1 }

D. mutex.wait { counter += 1 }

Solution

1. Step 1: Recall Mutex usage in Ruby

   Mutex uses the synchronize method to safely run code blocks.

2. Step 2: Check each option

   Only mutex.synchronize { ... } is the correct syntax to lock and unlock automatically.

3. Final Answer:

   mutex.synchronize { counter += 1 } -> Option A

4. Quick Check:

   Mutex uses synchronize method [OK]

Hint: Use synchronize to lock Mutex safely [OK]

Common Mistakes:

• Using lock or unlock methods incorrectly
• Trying to pass a block to lock or unlock
• Confusing wait with Mutex methods

3. What will be the output of this Ruby code?

require 'thread'
mutex = Mutex.new
counter = 0
threads = 5.times.map do
  Thread.new do
    10.times do
      mutex.synchronize { counter += 1 }
    end
  end
end
threads.each(&:join)
puts counter

medium

A. 10

B. 0

C. 5

D. 50

Solution

1. Step 1: Analyze thread and loop counts

   There are 5 threads, each incrementing counter 10 times, total increments = 5 * 10 = 50.

2. Step 2: Understand Mutex protection

   Mutex ensures increments happen safely without lost updates, so counter will be exactly 50.

3. Final Answer:

   50 -> Option D

4. Quick Check:

   5 threads * 10 increments = 50 [OK]

Hint: Multiply threads by increments with Mutex [OK]

Common Mistakes:

• Ignoring Mutex and expecting less than 50
• Confusing thread count with increments
• Assuming race conditions reduce count

4. Identify the problem in this Ruby code that uses threads:

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

medium

A. Thread.new syntax is incorrect

B. Threads are not joined, so program ends early

C. No Mutex used, so race condition may cause wrong counter value

D. Counter variable is not initialized

Solution

1. Step 1: Check thread safety of counter increment

   Multiple threads increment counter without synchronization, causing race conditions.

2. Step 2: Identify missing Mutex usage

   Without Mutex, increments can overlap and produce incorrect final value.

3. Final Answer:

   No Mutex used, so race condition may cause wrong counter value -> Option C

4. Quick Check:

   Missing Mutex causes race condition [OK]

Hint: Always use Mutex to protect shared variables [OK]

Common Mistakes:

• Thinking threads are not joined (they are)
• Assuming counter needs initialization (it is initialized)
• Believing Thread.new syntax is wrong

5. You want to safely update a shared hash results from multiple threads in Ruby. Which approach correctly ensures thread safety?

hard

A. Use a Mutex and wrap all results[key] = value assignments inside mutex.synchronize

B. Use Thread.new without any synchronization because Ruby hashes are thread-safe

C. Create a new hash inside each thread and merge them later without synchronization

D. Use sleep to delay threads and avoid conflicts

Solution

1. Step 1: Understand thread safety for shared hashes

   Ruby hashes are not thread-safe for writes; concurrent writes can cause errors or data loss.

2. Step 2: Use Mutex to protect hash updates

   Wrapping assignments inside mutex.synchronize ensures only one thread writes at a time.

3. Final Answer:

   Use a Mutex and wrap all results[key] = value assignments inside mutex.synchronize -> Option A

4. Quick Check:

   Mutex protects shared hash writes [OK]

Hint: Protect shared hash writes with Mutex synchronize [OK]

Common Mistakes:

• Assuming Ruby hashes are thread-safe for writes
• Using sleep to avoid conflicts (not reliable)
• Merging hashes without synchronization risks data loss