Question bank — Memory consistency models

True. Table mein TSO ka S→S ✅ hai, aur mechanism hai FIFO store buffer: stores issue hone ke order mein drain hote hain, isliye har observer unhe usi ek order mein dekhta hai. Dekho Store Buffers and Write Buffering.

True. Store-forwarding ke zariye, ek baad ka load same address ke liye buffered value seedha store buffer se padhta hai, isliye core apni write immediately dekhta hai chahe doosre cores abhi tak na dekhen — yeh exactly S→L (❌) relaxation in action hai.

False. SC ordering fix karta hai (ek single total interleaving jo har core ke program order ko respect kare — saare char pairs ✅) lekin typically sabse slow model hai kyunki S→L par ✅ us store-buffer bypass ko forbid karta hai jo real speed deta hai.

False. Coherence writes ko ek address par order karta hai; consistency (poora char-pair table) ops ko alag-alag addresses par order karta hai. Coherence necessary hai lekin strictly weaker hai. Dekho Cache Coherence.

True. Producer do stores karta hai (data=42 phir flag=1); TSO ka S→S ✅ hai, isliye data flag se pehle visible hai, aur jo bhi consumer flag dekhta hai woh data bhi dekhta hai. Dekho Memory Barriers and Fences.

False. Ek fence sirf apni khud ki position par ✅ ordering force karta hai (us se pehle ke ops vs baad ke ops); baaki jagah weak model ki ❌ freedoms abhi bhi apply hoti hain. Yeh SC locally khareedta hai, globally nahi.

Effectively False. Locks mein zaruri fences embed hote hain, relevant ❌ pairs ko lock boundaries par ✅ mein convert karte hain, isliye ek race-free program aise behave karta hai jaise SC ho — SC-for-DRF guarantee. Dekho Atomic Operations and Locks.

False. volatile sirf compiler ko ek value register mein cache karne se rokta hai; yeh koi hardware fences emit nahi karta, isliye weak-model row ka har ❌ threads ke beech ❌ hi rehta hai. Iske bajaye C++ Memory Model (acquire-release) ke atomics use karo.

True. Ek baad ke load ko earlier store drain hone se pehle complete karne dena ek S→L reorder hai (❌ cell), aur akele yahi dono loads ko stale 0 padhne de sakta hai. Dekho Out-of-Order Execution.

False. SC saare char pairs ✅ rakhta hai aur saare ops ka ek single global order enforce karta hai, isliye saare readers do independent writes ke order par agree karte hain.

Error: TSO L→L preserve karta hai (table mein ✅). TSO ki row mein sirf ek hi ❌ hai — S→L (ek store jo baad ke load se bypass hota hai). Mnemonic: "Stores Look Late."

Error: ek fence core ko slow karta hai — yeh buffer ke drain hone tak stall karta hai. Iska purpose ek ❌ pair ko ✅ mein convert karna hai (correctness); cost performance hai, isliye ise sirf wahan rakhte ho jahan ordering ki zarurat hai.

Error: ARM par saare char pairs ❌ hain, isliye tumhe dono chahiye — producer par release fence (data=42 ko flag=1 se pehle visible karta hai) aur consumer par acquire fence (flag-read ko data read se pehle force karta hai). Ek side akele doosre ke reorder ko open chhodti hai.

Error: coherence sirf same address ke writes ko order karta hai. Cross-address "x then y" question consistency table ka S→S pair hai, coherence nahi.

Error: TSO ordering govern karta hai (char-pair table), read-modify-write ki atomicity nahi. Atomic increments ke liye aur S→L cell ko ✅ mein force karne ke liye abhi bhi ek LOCK prefix (ya MFENCE) chahiye. Dekho Atomic Operations and Locks.

Error: ek core bhi apna store buffer mein rakh sakta hai — uska apna program order uske viewpoint se intact rehta hai (store-forwarding), lekin us store ka global visibility order doosre cores ke liye delayed hota hai.

Kyunki sirf stores buffer hote hain. Buffered store ek baad ke load ko pehle finish karne deta hai (S→L → ❌); FIFO S→S ko ✅ rakhta hai, aur non-buffered loads L→L aur L→S ko ✅ rakhte hain.

Store-forwarding: same address par baad ka load pending value seedha buffer se padhta hai, isliye core ko apni khud ki memory ka hamesha ek consistent, in-order view milta hai.

Ops ko label karo: S1 = Core 1 writes x=1, L2 = Core 1 reads y; S3 = Core 2 writes y=1, L4 = Core 2 reads x. Bad outcome r1==0 ka matlab hai L2 ne y padhaa S3 ke write se pehle, yaani global order mein L2 < S3; r2==0 ka matlab hai L4 < S1. Program order mein S1 < L2 aur S3 < L4. Chain karne par milta hai S1 < L2 < S3 < L4 < S1 — ek cycle, jise koi single total order contain nahi kar sakta. Isliye SC ise forbid karta hai.

Woh almost har ❌ open rakhte hain taaki ordinary memory ops reordered aur fast chalein; programmer sirf un handful synchronization points (locks, flags) par fences insert karta hai jahan actually ✅ ki zarurat hai, thodi mehnat ke badle many-core hardware par badi speedups milti hain.

Woh models non-multi-copy-atomic hain (upar define kiya): ek store alag-alag cores tak alag-alag times par pahunch sakta hai, isliye do readers do writes ko opposite orders mein observe kar sakte hain. TSO ek single total store order ke saath multi-copy-atomic hai, ise forbid karta hai.

Ek fence ✅ sirf un pairs ke liye force karta hai jo uski position par straddle karte hain (before → after); yeh door ke ops ke baare mein kuch nahi kehta, isliye unfenced regions mein weak model ki ❌ freedoms bani rehti hain.

Nahi. Koi doosra observer nahi hone se, program order us core ke apne view se store-forwarding ke zariye preserve hota hai — har reorder invisible hai, isliye table ki saari rows identical lagti hain.

Coherence le leta hai: saare cores us ek address par writes ka ek single order par agree karte hain, chahe consistency model ki char-pair row kitni bhi weak ho.

Doosra core unhe kisi bhi order mein dekh sakta hai (ARM par S→S ❌ hai), including doosre store ka effect dekhna jab pehla abhi visible nahi hua.

Nahi. L→S TSO par ✅ hai (sirf S→L ❌ hai), isliye load globally store se pehle ordered hai.

S→S ordering ke liye yeh redundant hai (TSO pehle se us cell mein ✅ hai), lekin yeh buffer drain karta hai aur surrounding S→L cell ko ✅ mein force karta hai — isliye yeh no-op nahi hai, bas S→S guarantee ke liye zaruri nahi.

SC. Har boundary ko fencing karna har ❌ ko ✅ mein force karta hai, ek single total order recover karta hai — maximum performance cost par.

Fence ordering ko semantically enforce karta hai, lekin near-zero cost par kyunki drain karne ke liye kuch nahi hai — stall pending stores ki sankhya ke proportional hota hai.