Write-through vs write-back: Question bank — Hinglish deep dive

5.4.6 · D5 · Hardware › Memory Hierarchy & Caches › Write-through vs write-back

Yeh page Write-through vs Write-back Cache Policies ke liye ek self-test hai. Har prompt mein ek real reasoning trap chhupa hai — woh tarah ka jo sahi lagta hai jab tak aap mechanism ko zor se bol ke na dekho. Answer cover karo, yes/no aur ek reason ke saath commit karo, phir reveal karo.

Shuru karne se pehle, neeche char plain-word anchors hain jo har jagah use hote hain. Har ek scratch se banaya gaya hai taaki yeh page apne aap mein complete ho — isko follow karne ke liye koi doosra note kholne ki zaroorat nahi.

Definition Woh char words jo is page ko carry karte hain

Dirty bit ::: ek single 1-bit flag jo har cache line (woh fixed 64-byte chunk jo cache ek unit ke roop mein store karta hai) se attached hota hai, jiska matlab hai "yeh cached copy change ho chuki hai aur memory ko abhi pata nahi." 0 = memory match karti hai, 1 = memory stale hai.
Eviction ::: woh moment jab cache ek line ko bahar nikalti hai nayi line ke liye jagah banane hetu. Write-back sirf isi waqt write ke liye memory ko touch karta hai.
Write buffer ::: ek chhota FIFO queue (typically 4–8 slots) jo memory ki taraf jaane wale writes ko pakadta hai taaki CPU ~100 ns memory write ka intezaar karne ki jagah aage badhta rahe.
Write-allocate ::: yeh rule ki "write miss par, pehle poori line cache mein fetch karo, phir usme write karo." Iska ulta hai no-write-allocate: write seedha memory mein bhejo aur cache ko skip karo. Write-back caches almost hamesha write-allocate ke saath pair hote hain.

Neeche woh picture hai jis par har sawaal tika hai — yaad karo ki ~1 ns aur ~100 ns costs kahan rahte hain, aur kab har policy unhe pay karti hai.

True or false — justify

True or false: Write-through mein, read miss kabhi bhi memory mein write trigger nahi kar sakta.

True — write-through memory ko hamesha current rakhta hai, isliye evicted line kabhi dirty nahi hoti; flush karne ke liye kuch nahi hota, sirf nayi line fetch karni hoti hai.

True or false: Write-back mein, ek read miss memory mein write force kar sakta hai.

True — agar jagah banane ke liye evict hone wali line ka dirty bit set hai, toh woh line memory mein flush zaroor hogi nayi read-fetched line aane se pehle, chahe triggering access ek read hi kyun na tha.

True or false: Dirty bit write-through caches mein bhi exist karta hai.

False — write-through lines kabhi memory se newer nahi hoti, isliye dirty bit hamesha 0 read karta aur koi information nahi deta; sirf write-back ko iske zaroorat hai.

True or false: Write-back hamesha write-through se strictly fewer memory writes issue karta hai.

False — reused lines ke liye yeh bahut kam issue karta hai, lekin write-once-then-evict pattern mein write-back phir bhi exactly ek memory write per line pay karta hai, write-through ke barabar — toh yeh tie kar sakta hai. "Always strictly fewer" bahut strong hai; "never more" sahi claim hai.

True or false: Write-back mein ek write hit workload chahe kuch bhi ho ~1 ns mein complete hota hai.

True — hit sirf line update karta hai aur dirty bit set karta hai; koi memory transaction critical path par nahi hota. 100 ns ka cost eviction tak defer hota hai.

True or false: Kaafi deep write buffer ke saath, write-through write latency cache latency ke kareeb aa sakti hai.

Bursts ke liye True jo buffer mein fit ho jaate hain — CPU sirf

T_{cache} + T_{buffer-insert}

dekhta hai. Yeh False ho jaata hai jab sustained write rate drain rate se zyada ho jaaye aur buffer fill ho jaaye, stalls force karte hue.

True or false: Write-back multi-core coherence ko write-through se simpler banata hai.

False — yeh ise harder banata hai. Kyunki memory stale ho sakti hai, doosra core memory par trust nahi kar sakta aur use kisi doosre core ke cache mein freshest copy dhundhna padta hai, cache-to-cache transfers aur snooping ki zaroorat padti hai.

True or false: Dirty bit line ke andar exactly kaunse bytes change hue hain track karta hai.

False — yeh per line ek bit hai, per byte nahi. Koi bhi write poori line ko dirty karta hai, isliye eviction sab 64 bytes write back karta hai chahe sirf ek byte change hua ho.

Spot the error

"Write-back faster hai kyunki yeh store par kabhi memory access nahi karta." — error dhundho.

Write-allocate ke under ek write miss pehle line ko memory se fetch karta hai, aur agar usne ek dirty line evict ki toh use flush bhi karta hai — toh ek store memory hit kar sakta hai. Write-back sirf write hits par memory avoid karta hai.

"Kyunki sirf ek byte change hua, write-back sirf woh ek byte memory mein bhejta hai." — error dhundho.

Memory transactions line-granular bursts hote hain (~64 bytes DRAM bus par); writeback poori line move karta hai. Per-byte tracking bahut kam gain ke liye bahut zyada hardware cost karti.

"Write-through ka total write time

T_{cache} + T_{memory}

hai, toh lagbhag 101 ns." — kya yeh hamesha observed CPU stall hai?

Write buffer ke saath nahi — CPU sirf

T_{buffer-insert}

(~1–2 ns) dekhta hai aur aage badhta hai; 100 ns memory write baad ke kaam ke saath overlap hoti hai. 101 ns transaction time hai, zaroor nahi ki stall time bhi ho.

"Write-back mein read miss hamesha

2 \times T_{memory}

cost karta hai." — error dhundho.

Doubled cost sirf tab apply hoti hai jab evicted line dirty ho (ek flush + ek fetch). Agar evicted line clean ho toh use simply discard kar diya jaata hai, aur miss usual single

T_{memory}

cost karta hai.

"Write-back bus traffic 100× reduce karta hai kyunki cache memory se 100× faster hai." — confusion dhundho.

Do alag ratios ko conflate kiya ja raha hai. 100× ek latency ratio hai (1 ns vs 100 ns). Traffic reduction Miss Rate ×

P_{dirty}

se aata hai (e.g. 0.05 × 0.5 ≈ 40×), raw speed se nahi.

"Dirty line evict karne par pehle nayi line fetch karte hain, phir purani ko write back karte hain." — ordering error dhundho.

Stale-copy safety ke liye zaruri hai ki dirty purani line ko memory mein pehle flush karo nayi fetch se pehle, warna purana data ka ek-maatra up-to-date copy destroy ho jaata.

Why questions

Write-through ko dirty bit ki zaroorat hi kyun nahi?

Kyunki yeh guarantee karta hai ki memory kabhi cache se peeche nahi hogi — har store turant propagate hoti hai — toh ek "memory is stale" flag permanently 0 aur bekar hoga.

Writeback line granularity par kyun hota hai chahe single-byte store ho?

Kyunki memory (DRAM) fixed bursts mein likhi jaati hai, aur cache sirf ek bit ke saath record karta hai "yeh line differ karti hai" — yeh track nahi karta kaunsa byte differ karta hai, isliye use poori line bhejni padti hai safe rehne ke liye.

Temporal locality write-back ko itni strongly kyun favor karti hai?

Same address par baar baar store cache par ~1 ns each hit karte hain, aur mehenga ~100 ns memory write ek baar eviction par pay hota hai — memory cost un saare saste writes par amortize ho jaata hai.

Write buffer write-through ko help kyun kar sakta hai lekin memory writes remove nahi kar sakta?

Buffer sirf latency hide karta hai memory writes ko CPU work ke saath overlap karke; har store eventually memory mein drain hota hai, toh total bus traffic unchanged rehta hai — buffer stall time trade karta hai, traffic nahi.

Write-back cross-core memory-consistency reasoning ko complicated kyun banata hai?

Kyunki "true" latest value ek private cache mein ho sakti hai aur memory mein nahi, doosre cores stale memory observe kar sakte hain, isliye ordering guarantees memory ke bajaye coherence protocol par depend karti hain.

Write-through "slower" hone ke bawajood aksar preferred kyun hai?

Iska simplicity, guaranteed up-to-date memory, aur easier coherence isko small L1 caches ya un systems ke liye attractive banata hai jahan correctness/simplicity peak write throughput se zyada important ho.

Edge cases

Edge case: Ek line ek baar likhi jaati hai, phir immediately evict ho jaati hai (koi reuse nahi). Kaun sa policy jeet ta hai?

Traffic par koi nahi jeetta — dono exactly ek memory write perform karte hain. Write-back ko yahan amortize karne ke liye kuch nahi milta, isliye "write-back hamesha jeetta hai" is pattern mein false hai.

Edge case: Ek pure streaming write workload (har address ek baar touch, kabhi reread nahi).

Deep write buffer ke saath write-through competitive aur simpler hai, kyunki write-back ka deferral koi reuse benefit nahi deta aur buffer sequential stream ke liye latency pehle se hi hide kar leta hai.

Edge case: Write buffer full hai aur ek nayi store arrive karti hai.

CPU tab tak stall karta hai jab tak ek buffer slot memory mein drain na ho — stalls tab appear hote hain jab sustained write rate

R_{write}

drain rate

N / T_{memory}

se zyada ho jaaye, toh ek "hidden" latency achanak visible ho jaati hai.

Edge case: Ek cache line dirty hai lekin program use dobara access nahi karta. Memory kab update hogi?

Kabhi nahi, jab tak line evict na ho ya explicit flush na run kare. Isliye write-back data ko indefinitely stale chhod sakta hai.

Edge case: Software ko write-back ke under memory copy abhi turant up-to-date chahiye — kaise?

Ek explicit cache-flush instruction use karo (e.g. CLFLUSH/CLWB on x86) dirty line ko memory mein force karne ke liye, aur usse order karne ke liye ek memory fence, kyunki normal execution sirf eviction par write back karta hai.

Edge case: Kisi bhi eviction se pehle same line par do writes write-back ke under. Kitne memory writes?

Exactly ek — dono stores dirty bit set/keep karte hain, aur single eviction final combined line ek baar flush karta hai.

Edge case: Zero writes lekin bahut saare read hits. Kya policies alag behave karti hain?

Nahi — koi stores nahi hone par propagate ya defer karne ke liye kuch nahi, koi line kabhi dirty nahi hoti, isliye write-through aur write-back identically behave karte hain. Poora distinction ek write problem hai.

Recall Lock in karne ke liye ek-line summary

Write-through = memory hamesha fresh, har store par pay karo, no dirty bit, easy coherence. Write-back = sirf cache fresh, har eviction par pay karo, dirty bit required, reuse ke saath best, harder coherence, memory current force karne ke liye explicit flush chahiye.

Related notes: Hinglish version · 5.4.01-CacheFundamentals · 5.4.05-Cache-ReplacementPolicies · 5.4.07-Cache-Coherence · 5.4.08-Write-Allocate-vs-No-Write-Allocate · 6.2.03-Memory-ConsistencyModels · 5.3.02-DRAM-Architecture