Locks: Foundations of Concurrent Control
Three Problems Locks Solve
3 Transactions (T1, T2, T3) engaged in stock trading on X, Y accounts
Problem 1: Correctness
Lost Updates
Without Locks:
T2: READ(x)=100
T1: WRITE(x=150)
T2: WRITE(x=130)
→ T1's update lost!
With Locks:
T2: [waits]→LOCK→READ(150)✓
Problem 2: Long Calculations
CPU Idle During Complex Logic
Serial Execution:
T2: Wait... then process data Y
T3: Wait... wait... then process data Z
→ Only 1 CPU core used!
Parallel Execution:
T2: LOCK(Y) → Process Y (parallel!)
T3: LOCK(Z) → Process Z (parallel!)
→ All CPU cores utilized!
Problem 3: IO Lag
CPU Idle During Disk Access
Read Operations:
Rs = Read Start (CPU→Disk)
Re = Read End (Disk→CPU)
Gap = ~5ms of waiting
Write Operations:
Ws = Write Start (CPU→Disk)
We = Write End (Disk confirms)
Gap = ~10ms of waiting
With Locks:
T2 uses CPU during T1's IO gaps
The Lock Cycle: How It Works
3 Transactions (T1, T2, T3) competing for 2 Concert Tickets (seat A, seat B)
Key Insight: T1 and T3 can work simultaneously (different tickets), but T2 must wait for T1.
Legend: Operation Types
Step-by-Step Lock Lifecycle
During IO gaps (Rs→Re), locks coordinate access between T1, T2, T3:
1⃣ Request
Transaction asks for lock on concert ticket
T3: REQ_LOCK(Ticket_B, lock)
2⃣ Get
Lock manager checks who gets access
Waiting: T2 waits
3⃣ Use Data
Read ticket data (IO) then process purchase (Logic)
Logic: Calculate total, apply discount
4⃣ Unlock
Release lock so others can buy
After: We (write confirmed)
Types of Locks: Why We Need Two Kinds
The Opportunity: Reads vs Writes are Different
Key Insight: Reading doesn't change data, writing does. So we can optimize!
Shared Lock (S-lock)
For Reading Data
Real Example: Checking Seat A-15 Availability
T2: S-LOCK(Seat_A15) → READ status = "available"
T3: S-LOCK(Seat_A15) → READ status = "available"
✅ All can check availability simultaneously!
Everyone can look at the same seat's status at once without interfering.
Exclusive Lock (X-lock)
For Writing Data
Real Example: Purchasing Seat A-15
T2: [BLOCKED] Can't even check availability
T3: [BLOCKED] Can't check or buy
Only one can buy (or even look) at a time!
During purchase, no one else can read OR write to prevent seeing partial updates.
Why This Design is Smart
Maximum Browsing
Multiple transactions can read the same data simultaneously (S + S = ✅)
Example: 1000 customers can check seat A-15's availability at the same time
Purchase Integrity
No transaction can read while another is writing (S + X = ❌)
Example: When someone is buying seat A-15, others can't even check it (prevents seeing partial updates)
No Double-Booking
Only one transaction can write at a time (X + X = ❌)
Example: Only one person can complete purchase of seat A-15
Lock Compatibility Matrix
| Shared (S) | Exclusive (X) | |
|---|---|---|
| Shared (S) | ✅ Compatible Many readers OK |
❌ Conflict No read during write |
| Exclusive (X) | ❌ Conflict No write during read |
❌ Conflict Only one writer |
Example: Bank Transfer with IO Timing
Key Point: During the Rs→Re and Ws→We gaps, other transactions can acquire locks on different accounts and make progress!