What is an "ack"? Is it simply a message confirming that the cache line has been dropped/invalidated?
ekr
Yes. "ack" stands for "acknowledge".
apoms
It's interesting to note that we can still satisfy the properties of coherence even if Processor 0 writes to the requested cache line after step 2 instead of waiting until after step 4.
Think about it this way: the cache system only needs to maintain a totally ordered and unique sequences of writes to the same cache line. If we wait until the ack's return we are actually satisfying the total order property AND a stronger guarantee: that the history of writes is immediately propagated to all processors. This guarantee ensures that we can't have stale reads because only one version of the data can be in any cache at one time. However, this comes at a latency cost: we now must wait until the ack's are received before proceeding.
Instead, if we write to the cache line after step 2 we can avoid that extra latency at the cost of stale reads. We introduce stale reads because if we allow the write to occur after step 2, that means it could occur before the requests to invalidate have reached each processor. In that situation, Processor 1 or 2 could read their local copy of the now modified cache line and see an old version of the data. Note, however, that the total order of writes is still maintained; the difference is that each Processor might be seeing an older version of the most up to date total order of writes but not one which is in conflict with the most recent total order of writes. Another situation which might give cause for concern is if Processor 1 or 2 initiates a write to their local copy after Processor 2 has passed step 2. This is fine though because the directory responsible for that cache line can ensure that it does not process a write request for that same cache line until it receives word that all invalidation ack's have been processed (in other words, that a previous write request has been atomically completed).
What is an "ack"? Is it simply a message confirming that the cache line has been dropped/invalidated?
Yes. "ack" stands for "acknowledge".
It's interesting to note that we can still satisfy the properties of coherence even if Processor 0 writes to the requested cache line after step 2 instead of waiting until after step 4.
Think about it this way: the cache system only needs to maintain a totally ordered and unique sequences of writes to the same cache line. If we wait until the ack's return we are actually satisfying the total order property AND a stronger guarantee: that the history of writes is immediately propagated to all processors. This guarantee ensures that we can't have stale reads because only one version of the data can be in any cache at one time. However, this comes at a latency cost: we now must wait until the ack's are received before proceeding.
Instead, if we write to the cache line after step 2 we can avoid that extra latency at the cost of stale reads. We introduce stale reads because if we allow the write to occur after step 2, that means it could occur before the requests to invalidate have reached each processor. In that situation, Processor 1 or 2 could read their local copy of the now modified cache line and see an old version of the data. Note, however, that the total order of writes is still maintained; the difference is that each Processor might be seeing an older version of the most up to date total order of writes but not one which is in conflict with the most recent total order of writes. Another situation which might give cause for concern is if Processor 1 or 2 initiates a write to their local copy after Processor 2 has passed step 2. This is fine though because the directory responsible for that cache line can ensure that it does not process a write request for that same cache line until it receives word that all invalidation ack's have been processed (in other words, that a previous write request has been atomically completed).