There are several non trivial notions assumed in <a href=Cache.html>this note</a>.
They are buried in terms ‘client’, ‘message’, etc.
It is naïvely imagined that a cache sits idle except when a client asks it to do a load or a store.
Some cache systems (such as the Keykos kernel logic that treated RAM as a disk cache) initiate background actions like copying dirty pages to disk if it seems unlikely that such traffic will interfere with the agenda of user mode programs.
Perhaps hardware caches should do that as well—perhaps they do.
But what is an ‘agendum’?
The computing platform must take as given that its clients (customers, if you wish) have things to do which can happen only with help from the platform.
I was taught in Multics lectures that a causal sequence of such agenda is called a ‘process’ and I use that term that way in many of these pages.
Modern terminology uses of ‘thread’ to capture this notion.
That the platform should have its own agenda surprises some.
Here are some:<ul>
<li>cleaning dirty pages,
<li>system checkpoint,
<li>garbage collection,
<li>disk defragmenting.</ul>
This is slightly related to the class of programs that Unix refers to as deamons which respond to agenda that originate outside the computer system.
<p>This is relevant to cache design in that messages can ‘pass in the mail’ and lead to surprising and perhaps erroneous results.
The spanning tree requirement is meant to help here but then we put limitations on the logic of the links between caches.
<hr>Issues such as these are buried in the <a href=http://www.cs.cmu.edu/~wing/publications/Wing02a.pdf>π-calculus</a> but not so deeply as in other academic disciplines.