Memory model — happens-before, acquire-release semantics: Foundations

5.2.27 · D1 · Coding › C++ Programming › Memory model — happens-before, acquire-release semantics

Parent note Memory Model padhne se pehle, tumhe har woh word aur symbol chahiye jo woh silently assume karta hai. Hum unhe ek ek karke build karte hain, zero se, har ek pichle ke upar.

Figure — Memory model — happens-before, acquire-release semantics

Figure dekho: do shelves (do CPU cores), aur har ek par boxes. Asli problem — jis par yeh poora topic hai — yeh hai ki jab core 1 koi box change karta hai, core 2 woh change instantly nahi dekhta. Ek delay hoti hai, jo unke beech wavy pipe ke roop mein draw ki gayi hai.

1. Thread — apni khud ki to-do list wala ek worker

Picture: do log (Thread 1, Thread 2) har ek ke paas ek to-do list, dono same boxes tak pahunch rahe hain. Is topic mein jo bhi mushkil hai woh isliye hota hai kyunki woh memory share karte hain lekin apni apni pace se chalta hai.

Topic ko iska kyun zaroorat hai: data race, happens-before, acquire, release — yeh sab do threads ke beech relationships describe karte hain. Ek thread ke saath koi problem hi nahi hoti.

2. Program order — top-to-bottom, jaise likha gaya

Definition Program order

Program order bas woh order hai jisme lines tumhare source mein appear hoti hain, upar se neeche, ek hi thread ke andar.

data = 42;      // line 1 — program order mein pehle
ready = true;   // line 2 — program order mein baad mein

Picture: ek arrow seedha to-do list ke neeche point karta hua. Yeh woh order hai jo tumne likha, zaroorat nahi ki machine kare bhi usi order mein — jo agle symbol ka poora surprise hai.

3. Reordering — woh surprise

Figure mein black arrow woh order hai jo tumne likha; red arrow ek aisa order hai jo machine actually run kar sakti hai. Teen alag villains yeh swap cause kar sakte hain:

compiler (dekho Compiler reordering and the as-if rule),
CPU instructions out of order run karta hua (dekho Out-of-order execution and store buffers (CPU)),
store buffer (SB) jo delay karta hai ki ek write shelf tak kab pahunche.

4. `std::atomic<T>` — ek indivisible box

Picture: solid lid wala ek box, taaki koi bhi andar dekhe toh ya purani value dekhe ya nayi value, kabhi smeared mix nahi. Important aur miss karna aasaan hai: atomic yeh guarantee sirf us atomic box khud ke liye deta hai — abhi tak woh surrounding ordinary boxes ke baare mein kuch nahi kehta. Unhe order karna ek alag kaam hai (iske liye §9–11 hain).

5. `.store()`, `.load()`, aur RMW — teen verbs

Picture: store = ek note andar daalna; load = andar jhankna; RMW = note uthana, edit karna, aur wapis rakhna koi box ko touch karne se pehle.

6. Data race — woh cheez jo humein avoid karni hai

Topic ko iska kyun zaroorat hai: poora memory model isliye exist karta hai taaki tum data races avoid kar sako missing ordering arrow supply karke. Yahan se sab kuch us arrow ko sahi tarike se banane ke baare mein hai.

7. Acquire aur Release — handshake ke do ends

Hume yeh do words cross-thread arrow define karne se pehle milne chahiye, kyunki woh arrow inhi se bana hai.

Figure mein release ek floor ke roop mein hai (⬇ cheezein neeche nahi gir sakti) aur acquire ek ceiling ke roop mein (⬆ cheezein upar nahi ja sakti). Ek saath, jab acquire-load exactly wahi value padhta hai jo release-store ne likhi, ek handshake banta hai — agli section ka cross-thread arrow.

Ek mutex bas yeh dono chipke hue hain: locking acquire hai, unlocking release hai.

8. Teen ordering relations — events ke beech arrows

Yahan "event" ka matlab bas ek read ya write hona hai. Hum events ko arrows se jodte hain. Pehle, notation ke do chhote tukde taaki arrows clearly padhe ja saken:

$A hb B ⟹ B sees every write done by A$

Woh formula payoff hai. Agar — aur sirf tab — tum ek write se ek read tak happens-before path draw kar sako, toh read guaranteed hai ki woh write dekhega. Koi path nahi ⇒ koi guarantee nahi ⇒ possible data race.

Figure follow karo: solid down-arrows sequenced-before hain, dashed cross-arrow synchronizes-with hai, aur (1) se (4) tak lamba green path woh happens-before chain hai jo data == 42 ko safe banata hai.

9. `memory_order` — strength dial

Definition Ordering tags

Har atomic operation ek strength tag carry karta hai, sabse weak se sabse strong tak:

relaxed — atomic + per-variable coherence only; doosre boxes ke liye koi ordering arrow nahi.
consume — acquire ka rarely-used, weaker cousin: yeh sirf un operations ko order karta hai jo loaded value par data-depend karte hain (same pointer/value follow karte hain), sab kuch load ke baad nahi. Practice mein har current compiler consume ko acquire mein promote karta hai, aur C++ standard iske use ko discourage karta hai; ise "acquire samjho, lekin historically pointer-chasing ke liye sasta hone ka iraada tha." Yahan isliye mention kiya gaya taaki enum list complete ho.
acquire (loads): iske baad koi read/write iske pehle move nahi karti (§7 ka upward gate).
release (stores): iske pehle koi read/write iske baad move nahi karti (§7 ka downward gate).
acq_rel (RMW): dono gates ek saath.
seq_cst (default): acquire+release plus ek single global order jis par saare seq_cst ops agree karte hain. Dekho Sequential consistency vs weak memory models.

Picture: ek dial "loose" (relaxed) se "strict" (seq_cst) tak. Zyada strictness = zyada guarantees = usually slower, kyunki CPU ko real fences insert karne padte hain (dekho std-atomic_thread_fence).

Prerequisite map

Har foundation agli ko feed karta hai; do arrows jo finally Happens-before par milte hain wahi poora point hai — ek thread ke andar se (sequenced-before), ek threads ke across (synchronizes-with).

Equipment checklist

Khud test karo — lekin yahan har line plain definition se ek step aage jaati hai, toh inhe mini-puzzles ki tarah padho, repeats ki tarah nahi.

Do threads ek alag-alag value store karte hain same atomic box mein; kya woh disagree kar sakte hain ki kaun sa store last tha?

Nahi — per-variable coherence ek single modification order force karta hai jis par saare threads agree karte hain.

Ek store buffer ek write delay karta hai; kya woh delay kabhi us thread ko affect karti hai jisne write kiya tha?

Nahi — ek thread hamesha apna latest write khud padhta hai; delay sirf doosre cores ko visible hai.

Ek acquire-load ek aisi value padhta hai jo release-store ne nahi balki us box par ek baad ke RMW ne likhi — kya handshake phir bhi banta hai?

Haan — RMW release sequence ka hissa hai, toh woh same baton carry karta hai.

Tum ek load ko consume tag karte ho time bachane ke liye; ek modern compiler actually kya emit karega?

acquire — har current compiler consume ko acquire mein promote karta hai.

relaxed per-variable coherence deta hai lekin kya nahi deta?

koi bhi ordering arrow jo doosre boxes ko is se relate kare — toh surrounding data ke liye koi happens-before nahi.

Acquire aur release ko pehle synchronizes-with se pehle kyun define kiya jaana chahiye?

kyunki synchronizes-with literally ek release store ke acquire load dwara padhe jaane se bana hota hai.

A hb B ⟹ B sees A

zor se padhte hain

agar A happens-before B, toh B ko A ki saari writes observe karna guaranteed hai.