Question bank — Memory model — happens-before, acquire-release semantics

False. Atomic sirf flag ki torn reads rokta hai; plain data ki ordering sirf happens-before edge se hoti hai, jiske liye release/acquire chahiye, sirf atomicity nahi. Dekho std-atomic and atomic operations.

Atomic ke liye True — relaxed phir bhi atomic hai, isliye atomic kabhi tear nahi hoga — lekin surrounding non-atomic data ke liye false, jise koi ordering nahi milti aur woh race karta hai.

False. Acquire ek one-way upward fence hai: yeh baad ki operations ko uske upar jaane se rokta hai. Pehle waali ops uski concern nahi hain.

False. Release ek one-way downward fence hai: yeh pehle ki ops ko uske upar pin karta hai; baad wali ops phir bhi uske upar float kar sakti hain.

False. acq_rel sirf memory ko ek specific synchronizes-with chain ke saath order karta hai. Global total order ke liye seq_cst chahiye; dekho Sequential consistency vs weak memory models.

False. Yeh edge sirf tab exist karta hai jab acquire actually woh released value (ya uski release sequence mein baad ki value) padhta hai. Ek purani value padhna matlab handshake kabhi complete nahi hua.

True. Agar $A\stackrel{hb}{\to }B$ aur $B\stackrel{hb}{\to }C$ toh $A\stackrel{hb}{\to }C$ — woh transitivity exactly yahi kaam karti hai ki ek release/acquire pair usse pehle sequenced saari cheezein saath le jaata hai.

False. Ek happens-before edge dono accesses ko order karta hai, isliye yeh race nahi hai. Data races ke liye ordering ki abscence chahiye.

True. Lock acquire ki tarah kaam karta hai, unlock release ki tarah, isliye critical sections apni writes us agli thread ko publish karti hain jo lock karti hai.

Spirit mein True — yeh sabse safe hai aur language default bhi hai — lekin yeh often slower hota hai, global total order ke liye extra fences ki keemat chukani padti hai. Pehle correctness, phir deliberately relax karo.

False. Yeh alag layers hain: compiler as-if rule ke under build time par reorder karta hai; CPU runtime par out-of-order execution aur store buffers ke zariye reorder karta hai. Ek memory tag ko dono ko defeat karna padta hai.

False. As-if rule guarantee karta hai ki single-thread execution program order mein dikhti hai; reordering sirf across threads observable hoti hai.

Error: relaxed koi synchronizes-with edge nahi banata, isliye data = 42 aur consumer ke read ke beech koi happens-before nahi hai — assert fire ho sakta hai. release/acquire use karo.

Error: release ek store ordering hai; load release nahi ho sakta. Load ko acquire (ya relaxed/seq_cst) use karna chahiye. Compiler reject karega ya semantics meaningless hongi.

Error: ek RMW jo pehle ki writes publish bhi kare aur doosron ki writes consume bhi kare, usse acq_rel chahiye. Pure acquire koi release side nahi deta, isliye pehle ki writes uske upar pin nahi hoti.

Error: synchronization data flow ke baare mein hai, wall-clock time ke baare mein nahi. Bina value ke writer se reader tak ek atomic ke zariye travel kiye, chahe "pehle koi bhi chala ho" — koi ordering nahi hogi.

Error: final destructor ko saare prior threads ki writes dikhni chahiye, jiske liye zero pahunchne wale decrement par acquire (ya acq_rel) chahiye, warna deletion un writes ke saath race karega.

Error: loop sahi se terminate hota hai (relaxed phir bhi modification order update karta hai) lekin koi hb edge nahi banata, isliye baad wala data read stale ho sakta hai. Load acquire hona chahiye.

Kyunki ordering data dependency se carry hoti hai: sirf tab jab published value physically writer se reader tak travel karti hai, reader writer ke prior work ko inherit kar sakta hai. Alag value matlab usne alag (ya koi nahi) publication observe ki.

acq_rel sirf individual synchronizes-with chains ke saath order karta hai; seq_cst additionally ek global total order force karta hai jis par saare seq_cst ops agree karte hain, woh IRIW/Dekker inconsistency defeat karte hue jo acq_rel permit karta hai.

Kyunki acq_rel koi cross-flag global order nahi deta — har reader dono stores ko caches se alag sequence mein propagate hote dekh sakta hai. Sirf seq_cst iska mana karta hai (woh IRIW case).

Standard racing accesses ko UB define karta hai taaki compilers assume kar sakein ki woh kabhi nahi hote aur freely optimize kar sakein; ek baar assumed-impossible behavior occur ho jaaye, koi bhi outcome (crash, silent corruption) permitted hai.

Compiler phir bhi as-if rule ke under plain write ko reorder ya cache kar sakta hai, aur portable code ko weak-memory CPUs par survive karna hai. Correctness model se aani chahiye, lucky platform se nahi.

Ek publisher ko sirf apna earlier kaam signal ke neeche pin karna hota hai (downward); ek subscriber ko sirf apne later reads signal dekhne ke baad pin karne hote hain (upward). One-way fences saste hain aur message passing ke liye exactly sufficient hain.

Counters aur statistics ke liye jahan sirf atomicity mayne rakhti ho (surrounding data order nahi karna), relaxed fence cost avoid karta hai — yeh Lock-free programming patterns ka ek staple hai.

Nahi. Stored value ki koi successful read nahi, koi synchronizes-with edge nahi banta, isliye kuch bhi publish nahi hota — reader kuch bhi nahi dekhega chahe baad mein ruk bhi jaaye.

Poori sequenced-before ordering intra-thread phir bhi hold karti hai — relaxed kabhi bhi single-thread program order ko weak nahi karta; weakness purely cross-thread hai.

Haan — har atomic ka ek single modification order hota hai, isliye saare threads us ek variable par writes ki sequence par agree karte hain, relaxed ke under bhi. Jo unhe nahi milta woh hai surrounding memory ki ordering.

Apne aap, koi synchronizes-with edge nahi banta; ek standalone fence sirf tab help karta hai jab doosri side par ek release ho aur ek atomic load/store unhe link kare.

Data ab race nahi karta (woh atomic hai), lekin consumer phir bhi stale data value padh sakta hai kyunki relaxed flag ke saath koi ordering nahi deta — logically galat, though UB nahi.

Thread creation ek happens-before edge establish karta hai: std::thread construction se pehle sequenced har cheez naye thread ke pehle operation se happens-before hai, isliye child parent ki prior writes dekhta hai.