Editing Cache (computing) (section)

==={{Anchor|Dirty|WRITEPOLICIES|WRITE-BACK|WRITE-BEHIND|WRITE-THROUGH|WRITE-AROUND}}Write policies===
[[File:Write-through with no-write-allocation.svg|thumb|380px|A write-through cache without write allocation]]
[[File:Write-back with write-allocation.svg|thumb|500px|A write-back cache with write allocation]]

Cache writes must eventually be propagated to the backing store. The timing for this is governed by the ''write policy''. The two primary write policies are:<ref>{{Cite web|url=https://www.linuxjournal.com/article/7105|title=Understanding Caching|last=Bottomley|first=James|date=2004-01-01|website=Linux Journal|access-date=2019-10-01}}</ref>
* ''Write-through'': Writes are performed synchronously to both the cache and the backing store.
* ''Write-back'': Initially, writing is done only to the cache. The write to the backing store is postponed until the modified content is about to be replaced by another cache block.

A write-back cache is more complex to implement since it needs to track which of its locations have been written over and mark them as ''dirty'' for later writing to the backing store. The data in these locations are written back to the backing store only when they are evicted from the cache, a process referred to as a ''lazy write''. For this reason, a read miss in a write-back cache may require two memory accesses to the backing store: one to write back the dirty data, and one to retrieve the requested data. Other policies may also trigger data write-back. The client may make many changes to data in the cache, and then explicitly notify the cache to write back the data.

Write operations do not return data. Consequently, a decision needs to be made for write misses: whether or not to load the data into the cache. This is determined by these ''write-miss policies'':
* ''Write allocate'' (also called ''fetch on write''): Data at the missed-write location is loaded to cache, followed by a write-hit operation. In this approach, write misses are similar to read misses.
* ''No-write allocate'' (also called ''write-no-allocate'' or ''write around''): Data at the missed-write location is not loaded to cache, and is written directly to the backing store. In this approach, data is loaded into the cache on read misses only.

While both write policies can Implement either write-miss policy, they are typically paired as follows:<ref name="HennessyPatterson2011">{{cite book|last1=Hennessy|first1=John L.|url=https://books.google.com/books?id=v3-1hVwHnHwC&pg=SL2-PA12|title=Computer Architecture: A Quantitative Approach|last2=Patterson|first2=David A.|publisher=Elsevier|year=2011|isbn=978-0-12-383872-8|page=B–12|language=en}}</ref><ref>{{cite book|title=Computer Architecture A Quantitative Approach|last1=Patterson|first1=David A.|last2=Hennessy|first2=John L.|isbn=1-55860-069-8|date=1990|page=413|publisher=Morgan Kaufmann Publishers}}</ref>
* A write-back cache typically employs write allocate, anticipating that subsequent writes or reads to the same location will benefit from having the data already in the cache.
* A write-through cache uses no-write allocate. Here, subsequent writes have no advantage, since they still need to be written directly to the backing store.

Entities other than the cache may change the data in the backing store, in which case the copy in the cache may become out-of-date or ''stale''. Alternatively, when the client updates the data in the cache, copies of that data in other caches will become stale. Communication protocols between the cache managers that keep the data consistent are associated with [[cache coherence]].