Race condition problem in Operating Systems - Step-by-Step Execution

Concept Flow - Race condition problem

Start: Two processes want to access shared data

↓

Process 1 reads data

↓

Both processes modify data independently

↓

Process 1 writes data back

↓

Data overwritten, inconsistent state

↓

Race condition occurs

Two or more processes access and modify shared data at the same time without proper coordination, causing unexpected results.

Execution Sample

Operating Systems

SharedCounter = 0
Process1: temp = SharedCounter
Process1: temp = temp + 1
Process2: temp = SharedCounter
Process2: temp = temp + 1
Process1: SharedCounter = temp
Process2: SharedCounter = temp

Two processes read, increment, and write back a shared counter without synchronization, causing a race condition.

Analysis Table

Step	Process	Action	SharedCounter Before	Temp Value	SharedCounter After
1	Process1	Read SharedCounter	0	0	0
2	Process1	Increment temp	0	1	0
3	Process2	Read SharedCounter	0	0	0
4	Process2	Increment temp	0	1	0
5	Process1	Write temp to SharedCounter	0	1	1
6	Process2	Write temp to SharedCounter	0	1	1

💡 Both processes wrote '1' causing the counter to increase only once instead of twice, showing a race condition.

State Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6
SharedCounter	0	0	0	0	0	1	1
Process1_temp	N/A	0	1	1	1	1	1
Process2_temp	N/A	N/A	N/A	0	1	1	1

Key Insights - 3 Insights

Why does the SharedCounter only increase by 1 instead of 2?

Because both processes read the same initial value before either writes back, they overwrite each other's updates as shown in steps 5 and 6 of the execution_table.

Why is it a problem that both processes read SharedCounter before writing?

Reading before writing without coordination means each process works with stale data, causing lost updates as seen in steps 3 and 4.

How does this relate to the term 'race condition'?

The processes 'race' to write their changes, and the final result depends on who writes last, leading to unpredictable and incorrect outcomes.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of SharedCounter after step 5?

A 2

B 0

C 1

D Undefined

💡 Hint

Check the 'SharedCounter After' column at step 5 in the execution_table.

At which step does Process2 read the SharedCounter value?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look for Process2's 'Read SharedCounter' action in the execution_table.

If Process1 wrote to SharedCounter before Process2 read it, what would be the SharedCounter value after step 6?

A 2

B 0

C 1

D Cannot determine

💡 Hint

Consider the order of writes and reads in the execution_table and how it affects the final value.

Concept Snapshot

Race condition occurs when multiple processes access and modify shared data simultaneously without coordination.
This causes unpredictable results because updates can overwrite each other.
Example: Two processes incrementing a shared counter without synchronization may lose one increment.
To prevent this, use locks or synchronization methods to control access.

Full Transcript

A race condition problem happens when two or more processes try to use the same data at the same time without proper control. For example, if two processes read a shared counter as zero, both add one, and then both write back, the counter only increases once instead of twice. This happens because the second process overwrites the first process's update. The execution table shows each step: both processes read zero, increment their own copy, then write back one. The final shared counter is one, not two. This is a race condition because the processes race to write their changes, and the last write wins, causing lost updates. To avoid this, processes must coordinate using locks or other synchronization tools to ensure only one process changes the data at a time.