Thread safety concepts in Ruby - Step-by-Step Execution

Concept Flow - Thread safety concepts

Start Thread 1

↓

Access shared data

↓

Modify shared data

↓

Race condition?

↓

Data corrupted

↓

End

Two threads try to access and modify shared data at the same time, which can cause conflicts unless controlled.

Execution Sample

Ruby

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

This code starts 5 threads, each adding 1 to a shared counter 1000 times, then prints the final counter value.

Execution Table

Step	Thread	Action	counter before	counter after	Note
1	T1	Read counter	0	0	Reads current counter value 0
2	T1	Add 1	0	1	Adds 1 to local value
3	T2	Read counter	0	0	Reads counter before T1 writes
4	T1	Write counter	0	1	Writes updated counter 1
5	T2	Add 1	0	1	Adds 1 to local value
6	T2	Write counter	0	1	Overwrites counter with 1, lost increment
...	...	...	...	...	...
Final	All	After all increments	?	less than 5000	Counter less than expected due to race conditions

💡 Threads finish but counter is less than 5000 because increments overlapped and some were lost.

Variable Tracker

Variable	Start	After T1 step 2	After T2 step 6	Final
counter	0	1	1	<5000 (less than expected)

Key Moments - 3 Insights

Why does the counter end up less than 5000 even though 5 threads add 1000 each?

Because threads read and write the counter at the same time without coordination, some increments overwrite others. See execution_table steps 3-6 where T2 reads before T1 writes, causing lost updates.

What is a race condition in this example?

A race condition happens when multiple threads access and modify shared data without proper control, leading to unpredictable results. Here, threads race to update 'counter' causing incorrect final value.

How can we fix this problem?

By using synchronization tools like Mutex to make sure only one thread changes 'counter' at a time, preventing overlapping updates.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of 'counter' after Thread 2 writes in step 6?

A 1

B 0

C 2

D 1000

💡 Hint

Check the 'counter after' column in step 6 of execution_table.

At which step does the race condition cause a lost increment?

A Step 2

B Step 4

C Step 6

D Final

💡 Hint

Look at when Thread 2 overwrites the counter without adding its increment properly (step 6).

If we add a Mutex lock around the increment, how would the final counter value change?

A It would be less than 5000

B It would be exactly 5000

C It would be zero

D It would be random

💡 Hint

Mutex prevents race conditions, so all increments count correctly, see key_moments answer 3.

Concept Snapshot

Thread safety means controlling access to shared data
Without control, threads can overwrite each other (race condition)
Use Mutex or locks to allow one thread at a time
This prevents lost updates and data corruption
Always protect shared variables in multithreaded code

Full Transcript

This example shows two or more threads trying to update the same variable 'counter' at the same time. Because they read and write without waiting for each other, some increments get lost. This is called a race condition. The execution table traces how Thread 1 reads and writes the counter, then Thread 2 reads the old value before Thread 1 writes, causing Thread 2 to overwrite the update. The final counter is less than expected. To fix this, we use a Mutex lock so only one thread changes the counter at a time, ensuring the final count is correct. Thread safety is about preventing these conflicts when multiple threads share data.