Thread synchronization with Mutex in Ruby - Step-by-Step Execution

Concept Flow - Thread synchronization with Mutex

Start Threads

↓

Thread tries to lock Mutex

↓

Access shared

↓

resource

↓

Unlock Mutex

↓

Threads finish

Threads try to lock a mutex before accessing shared data. If locked, others wait. After use, mutex unlocks allowing next thread.

Execution Sample

Ruby

require 'thread'

mutex = Mutex.new
counter = 0

threads = 2.times.map do
  Thread.new do
    mutex.synchronize do
      temp = counter
      sleep(0.1)
      counter = temp + 1
    end
  end
end
threads.each(&:join)
puts counter

Two threads safely increment a shared counter using a mutex to avoid conflicts.

Execution Table

Step	Thread	Action	Mutex Locked?	counter Value	Notes
1	Thread 1	Attempts to lock mutex	No	0	Mutex is free, Thread 1 locks it
2	Thread 1	Reads counter into temp	Yes	0	temp = 0
3	Thread 1	Sleeps (simulate work)	Yes	0	Holding lock during sleep
4	Thread 1	Sets counter = temp + 1	Yes	1	counter updated to 1
5	Thread 1	Unlocks mutex	No	1	Mutex released
6	Thread 2	Attempts to lock mutex	No	1	Mutex free, Thread 2 locks it
7	Thread 2	Reads counter into temp	Yes	1	temp = 1
8	Thread 2	Sleeps (simulate work)	Yes	1	Holding lock during sleep
9	Thread 2	Sets counter = temp + 1	Yes	2	counter updated to 2
10	Thread 2	Unlocks mutex	No	2	Mutex released
11	Main	Prints counter	No	2	Final counter value is 2

💡 Both threads completed, mutex unlocked, counter incremented safely to 2

Variable Tracker

Variable	Start	After Thread 1	After Thread 2	Final
counter	0	1	2	2
mutex Locked?	No	No	No	No

Key Moments - 3 Insights

Why does the counter not become 1 instead of 2 after both threads run?

Because each thread locks the mutex before reading and updating counter, they run one after another safely (see execution_table steps 1-5 and 6-10). This prevents race conditions.

What happens if a thread tries to lock the mutex while it is already locked?

The thread waits (blocks) until the mutex is unlocked by the other thread, as shown in the flow where one thread locks and the other waits.

Why do we use mutex.synchronize instead of manually locking and unlocking?

mutex.synchronize ensures the mutex is always unlocked even if an error occurs inside the block, making code safer and simpler (see code sample).

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of counter after Thread 1 unlocks the mutex?

A 0

B 1

C 2

D Undefined

💡 Hint

Check step 5 in the execution_table where Thread 1 unlocks the mutex and counter is updated.

At which step does Thread 2 acquire the mutex lock?

A Step 9

B Step 2

C Step 6

D Step 11

💡 Hint

Look at the 'Mutex Locked?' column in the execution_table for Thread 2 locking the mutex.

If we remove the mutex, what problem would most likely happen?

A Race condition causing incorrect counter value

B Threads run sequentially without issues

C Counter increments correctly to 2

D Program crashes immediately

💡 Hint

Think about why mutex is used in the code sample and what happens if threads access shared data simultaneously.

Concept Snapshot

Mutex ensures only one thread accesses shared data at a time.
Use mutex.synchronize { ... } to lock and unlock safely.
Threads wait if mutex is locked, preventing race conditions.
Without mutex, shared data can be corrupted.
Mutex unlocks automatically after block ends.

Full Transcript

This example shows two threads incrementing a shared counter safely using a mutex. Each thread locks the mutex before reading and updating the counter, then unlocks it. The execution table traces each step, showing when threads lock, read, sleep, update, and unlock. The variable tracker shows counter changes from 0 to 2. Key moments clarify why mutex prevents race conditions and why synchronize is safer. The quiz tests understanding of mutex locking steps and consequences of removing mutex.