Concurrency — std - thread, std - mutex, std - lock_guard, std - unique_lock: Visual walkthrough

5.2.24 · D2 · Coding › C++ Programming › Concurrency — std - thread, std - mutex, std - lock_guard, s

Hum ek central result build karte hain: kyun do threads jo ek shared counter mein 100000 add kar rahe hain, 2 se lekar 200000 tak koi bhi value pe khatam ho sakte hain — aur kyun add ko lock mein wrap karna hamesha exactly 200000 deta hai.

Step 1 — "Thread" kya hota hai, do haathon ke roop mein

KYA. Ek thread execution ki ek single line hai — socho ek haath instructions ki list pe neeche ja raha hai, unhe ek ke baad ek karta hua. Do threads = do haath ek saath chal rahe hain apni apni instruction lists pe.

YE YAHAN SE KYUN SHURU. Race dekhne se pehle, humein dekhna hoga ki "ek saath" literally hai: do haath shuddh shaalinta se baari nahi le rahe. Kuch bhi unhe coordinate nahi karta jab tak hum coordination add nahi karte.

PICTURE. Do haath, dono ek hi chhota program ++counter chala rahe hain, dono ek shared box ki taraf badh rahe hain jis par counter likha hai.

Parent ka kitchen analogy ek line mein: do cooks, ek counter. Poora model dekhne ke liye parent topic dekhein.

Step 2 — `++counter` actually kya hai: teen chhote moves

KYA. Ek akela symbol ++counter hardware ke liye ek action nahi hai. Yeh teen hain:

$READ r \leftarrow counter ⟶ ADD r \leftarrow r + 1 ⟶ WRITE counter \leftarrow r$

Symbols ko left se right padhte hain:

$r$ — ek private scratch value jo thread ke apne CPU register mein rehti hai; har haath ka apna alag $r$ hota hai.
$r \leftarrow counter$ — READ: box ka current number apne private $r$ mein copy karo.
$r \leftarrow r + 1$ — ADD: sirf apni copy mein ek add karo. Box yahan untouched rehta hai.
$counter \leftarrow r$ — WRITE: apna private $r$ wapas shared box mein stamp karo.

YEH DECOMPOSITION KYUN. Poori bimari READ aur WRITE ke beech ke gap mein rehti hai. Agar hum ++counter ko ek instant action maante, koi race exist nahi kar sakti. Ise teen mein todna interruptible middle ko expose karta hai.

PICTURE. Teen arrows READ → ADD → WRITE, private $r$ ek chhote side-pad ke roop mein shared box se alag draw kiya hua.

Step 3 — Ek possible interleaving jo count kho deta hai

KYA. Ab dono haathon ko apne teen moves chalane do, aur time ko ek shared timeline pe tick karne do. Maano box $counter = 7$ se shuru hota hai. Yahan ek buri interleaving hai (bahut saari mein se jo OS choose kar sakta hai):

time	Thread A	Thread B	box `counter`
$t_{1}$	READ $r_{A} = 7$		$7$
$t_{2}$		READ $r_{B} = 7$	$7$
$t_{3}$	ADD $r_{A} = 8$		$7$
$t_{4}$		ADD $r_{B} = 8$	$7$
$t_{5}$	WRITE $\to 8$		$8$
$t_{6}$		WRITE $\to 8$	$8$

$r_{A}, r_{B}$ — do haathon ki alag alag scratch values.
Dono ne $7$ read kiya pehle ki kisi ne bhi likha → dono ne $8$ compute kiya → box $8$ pe khatam, $9$ nahi.

GALAT KYUN HAI. Do ++ operations box ko $2$ se badhani chahiye thi (yani $9$ tak). Yahan ek increment gayab ho gaya kyunki B ne stale value $7$ read ki jo A ne abhi update nahi ki thi.

PICTURE. Timeline jismein dono READs same value $7$ pe land kar rahe hain (red), dono WRITEs same $8$ stamp kar rahe hain (orange) — woh collision jo count khaata hai.

Step 4 — Yeh kitna bura ho sakta hai? Outcomes ki poori range

KYA. 100000 increments per thread ke saath, agar hum Step 2 ke read/write model ko sach maanein, sampled value kuch bhi ho sakti hai is interval mein

$2 \leq counter_{final} \leq 200000$

bounds padhte hain:

Upper $200000$ — lucky run jahan koi bhi do operations kabhi overlap nahi karte; $200000$ increments mein se har ek bachta hai.
Lower $2$ — worst interleaving. Maano thread A pehle apne saare $100000$ READs karta hai, har baar value $0$ apne private $r$ mein grab karta hai (box kabhi aage nahi badhta kyunki A kabhi write nahi karta abhi tak). Phir thread B completion tak chalta hai, box ko $100000$ tak drive karta hai. Aakhir mein A apne writes karta hai, har baar ek stale $r$ wapas stamp karta hai — aakhri write box ko sirf $1$ pe chhod deta hai. Dono threads mein symmetric bookkeeping se true theoretical floor $2$ ban jaata hai (har thread ki final write wahi hai jo guaranteed land hoti hai). Yeh $100001$ nahi hai: koi bhi cheez ek poore thread ke kaam ko preserve hone par force nahi karti.

ACTUAL FLOOR KYUN MAAYENE RAKHTA HAI. Ek tempting galat guess yeh hai ki "kam se kam ek thread ke 100000 survive karte hain, toh $\geq 100001$ ." Yeh galat hai — stale reads almost sab kuch wipe out kar sakti hain. Floor ko $2$ jaana jaanna yeh batata hai ki ek race ek minor rounding error nahi hai; yeh almost saara kaam tabah kar sakta hai.

YEH SIRF EK CARICATURE KYUN HAI. Kyunki access UB hai, "kahi $[2, 200000]$ mein" bhi ek promise nahi hai — ek real run crash ho sakta hai ya kisi bhi counting argument se bahar garbage print kar sakta hai. Range ek teaching lower/upper bound on the counting model hai, koi spec nahi.

PICTURE. $2$ se $200000$ tak number line jismein possible results scattered hain — baat yeh hai ki koi single "answer" nahi hai.

Step 5 — Fix: READ→ADD→WRITE ko unsplittable banao

KYA. Teen moves ke around ek mutex (ek single token) rakho. Ek haath ko andar jaane ke liye token hold karna zaroori hai; sirf ek token exist karta hai.

std::mutex mtx;
{ std::lock_guard<std::mutex> lk(mtx);  // grab token here
  ++counter;                            // READ-ADD-WRITE, uninterrupted
}                                       // lk destroyed -> drop token here

mtx — single token object.
lk — RAII grip. RAII ka matlab hai Resource Acquisition Is Initialization: yeh idea ki ek resource ka ownership (yahan, lock) ek object ke lifetime se tied hai — yeh constructor mein acquire karta hai aur destructor mein release karta hai. Dekhein RAII and resource management. Toh lk token ko build hone par grab karta hai aur block khatam hone par drop karta hai — chahe exception bhi fly kare.
Block { ... } — critical section: ek baar mein zyada se zyada ek haath andar.

KAAM KYUN KARTA HAI. Doosra haath ab READ aur WRITE ke beech nahi slip kar sakta — woh token pe blocked hai jab tak pehla haath teeno moves finish karke token drop nahi karta. Step 3 mein jo gap counts kho raha tha woh ab exist nahi karta.

PICTURE. Thread A token hold karte hue, READ→ADD→WRITE bina kisi interruption ke karta hua; Thread B band gate par frozen, wait karta hua.

Step 6 — Token ke saath same start dekhna: koi count nahi khoota

KYA. Step 3 ka start ( $counter = 7$ ) replay karo lekin token se serialized:

time	Thread A	Thread B	box `counter`
$t_{1}$	lock, READ $r_{A} = 7$	blocked	$7$
$t_{2}$	ADD $r_{A} = 8$	blocked	$7$
$t_{3}$	WRITE $\to 8$ , unlock	blocked	$8$
$t_{4}$		lock, READ $r_{B} = 8$	$8$
$t_{5}$		ADD $r_{B} = 9$	$8$
$t_{6}$		WRITE $\to 9$ , unlock	$9$

B ka READ ab $8$ dekhta hai — woh fresh value jo A ne likhi — toh B $9$ compute karta hai. Do increments, box $2$ badhta hai. Sahi. Aur kyunki lock proper synchronization bhi establish karta hai, yeh ab defined behavior hai — ek real promise, koi caricature nahi.

YEH POORA POINT KYUN HAI. Serialization "ek saath" ko sirf shared box ke liye "ek-ek karke" mein wapas badal deta hai. Dono haath baki jagah parallel chalte rehte hain; woh sirf token par queue karte hain.

PICTURE. Corrected timeline: B ka READ arrow ab $8$ pe land karta hai, stale $7$ pe nahi.

Step 7 — Degenerate cases (taaki aap kisi unseen mein na faso)

KYA & KYUN, har ek ek aisa corner jismein reader stumble kar sakta hai:

Definition Edge cases, covered

Zero threads touch it / single-threaded — doosra haath exist hi nahi karta, toh koi interleaving possible nahi; mutex harmless lekin useless overhead hai. Race ke liye do ya zyada concurrent accesses chahiye.
Sab reads, koi write nahi — agar koi nahi likhta, har haath same fixed number dekhta hai; lock ke bina bhi koi race nahi. Khatre ke liye kam se kam ek writer zaroori hai.
join() karna bhool gaye — agar main ek haath ke khatam hone se pehle end ho jaata hai, toh ek joinable thread ka destructor std::terminate() call karta hai; program abort ho jaata hai counter dekhne se pehle hi. Hamesha join() ya detach() karo.
Sab kuch ek mutex se lock karo — sahi lekin slow: haath unrelated kaam ke liye bhi queue karte hain. Pehle correctness, phir critical section ko narrow karo (Step 5 ka { } deliberately chhota hai).

PICTURE. 2×2 grid: (single hand → safe), (many readers → safe), (writer + reader unlocked → race), (writer + reader locked → safe).

Ek-picture summary

Upar sab kuch compress kiya: unprotected path READ/ADD/WRITE ko split karta hai aur ek count kho deta hai; protected path trio ko poora run karne par majboor karta hai, toh count bachta hai.

Recall Feynman Retelling — poora walkthrough simple shabdon mein

Do bachche ek shared card par likhe ek number ko ek ek karke badhana chahte hain. Badhane ke liye, ek bachche ko (1) number read karna hota hai, (2) apne dimaag mein ek add karna hota hai, (3) purana number mitaana aur naya likhna hota hai. Problem yeh hai: jab bachcha A abhi bhi dimaag mein add kar raha hai, bachcha B card se purana number read kar leta hai. Dono same naya number likhte hain — toh do bumps ne card ko sirf ek badhaya. Ek poora bump gayab ho gaya, aur kyunki yeh split-second timing par depend karta hai, aap ise reliably reproduce nahi kar sakte — actually, kyunki yeh "undefined behavior" hai, card almost kuch bhi dikhaa sakta hai, chahe kuch bhi silly ho. Sabse buri timing mein, almost har bump wipe ho jaata hai. Fix hai ek token table par: card tab hi touch kar sakte ho jab token haath mein ho, aur exactly ek token hai. Ab bachcha B tab tak read nahi kar sakta jab tak bachcha A likhna finish karke token nahi chhod deta — B ko hamesha A ki fresh value milti hai. lock_guard ek jaadui strap hai: jis pal bachcha table se door jaata hai, token automatically gir jaata hai, toh koi bhi use haath mein pakde nahi ja sakta (yeh aadat ki "jaana" ko "chodna" se baandhna wahi hai jo bade log RAII kehte hain). Same parallel bachche, same shared card — lekin touching ab single-file hai, aur har bump count karta hai.

Connections

RAII and resource management — lock_guard grip jo token auto-drop karti hai
std::atomic and lock-free programming — ++counter ko bina lock ke ek unsplittable step banao
std::condition_variable — jab ek haath ko sirf token ke liye nahi, ek condition ke liye wait karna ho
Deadlock and lock ordering — do tokens ke saath kya galat hota hai
Undefined behavior in C++ — data race formally kya hoti hai
Move semantics — kyun ek std::thread (ek unique haath ka owner) move-only hota hai