The write commits at the end of step 4, after all the other processors "snoop" the request. Let's say we are the processor A that is writing to X. From here on out, no other processor has the value in its cache. If processor B needs to read the value, it must make a request. But, our processor A is in M state and has control of X. So, A will write to the cache and flush the line before B's request can be completed. Then, when B's request will be completed, it will read the data from R0 that is guaranteed to be in X.
jmc
The write is not committed after step 3 because although at this point the processor has been granted the bus (hence no other processors can send a command until it's done), other processors can still be performing reads (in states S, E, M) and writes (in states E, M) on their locally cached copy of X which don't require a bus transaction. Only after the other processors have snooped (i.e. acknowledged) the command is the write committed, because at this point all caches have been updated to a state which, if they were to read X, would get the newly written value of X.
paracon
I was wondering if acknowledgment at end of step 4 implies writing to shared L3 cache or memory or is that implementation dependent? Like in @tarabyte's example, the value written by processor A could either be given to processor B directly or it would need to be written to memory/shared L3 cache, so that A has the updated value, and memory coherence is maintained.
jmc
@paracon I think what you're asking is orthogonal to the process discussed on this slide; i.e., yes, it's a separate implementation choice. @tarabyte's explanation was "looking forward" to the next time some processor B tries to read X, which A has modified locally in its cache -- then A will have to get the modified value to B, whether directly or through flushing to L3 or memory. But this does not happen at step 4 of this slide; at step 4, the other processors (including B) have only acknowledged A's BusRdX request and made the necessary state changes. It would be after all the steps on this slide that the other processor B could make its request and possibly cause A to send its value or flush to L3 or memory.
paracon
@jmc, Oh! so would you say that the state change from S/M to Invalid happens independently of the value being flushed to memory. The reason I find it to be confusing is that I feel if the flush does not happen, though future requests from other processors could feel that they have the latest data, but they might not.
jmc
@paracon I think I may have misunderstood your question. I took it to be asking about whether processor A flushes its value at step 4, but now I see that it makes more sense for you to be asking whether B flushes at step 4. Yes, B will indeed flush to L3/memory (if it has a modified value of X, which can only be true if it's in state M) when it snoops A's request in step 4 because that is part of the transition procedure when you receive a BusRd or BusRdX message from another processor.
hpark914
The write commits after step 4, even though R0 technically still hasn't been written into the cache line until step 6, the other processors have snooped the request and thinks that it has.
lfragago
It is important to know the distinction between effectively writing the line( the new value is now on the cache), and write committing the line:
In simple terms:
Write commit: The rest of the processors having that line, have enough information at this point about the line state, so that they will EVENTUALLY (not necessarily at this moment) read the new result when reading the line.
The write commits at the end of step 4, after all the other processors "snoop" the request. Let's say we are the processor A that is writing to X. From here on out, no other processor has the value in its cache. If processor B needs to read the value, it must make a request. But, our processor A is in M state and has control of X. So, A will write to the cache and flush the line before B's request can be completed. Then, when B's request will be completed, it will read the data from R0 that is guaranteed to be in X.
The write is not committed after step 3 because although at this point the processor has been granted the bus (hence no other processors can send a command until it's done), other processors can still be performing reads (in states S, E, M) and writes (in states E, M) on their locally cached copy of X which don't require a bus transaction. Only after the other processors have snooped (i.e. acknowledged) the command is the write committed, because at this point all caches have been updated to a state which, if they were to read X, would get the newly written value of X.
I was wondering if acknowledgment at end of step 4 implies writing to shared L3 cache or memory or is that implementation dependent? Like in @tarabyte's example, the value written by processor A could either be given to processor B directly or it would need to be written to memory/shared L3 cache, so that A has the updated value, and memory coherence is maintained.
@paracon I think what you're asking is orthogonal to the process discussed on this slide; i.e., yes, it's a separate implementation choice. @tarabyte's explanation was "looking forward" to the next time some processor B tries to read X, which A has modified locally in its cache -- then A will have to get the modified value to B, whether directly or through flushing to L3 or memory. But this does not happen at step 4 of this slide; at step 4, the other processors (including B) have only acknowledged A's BusRdX request and made the necessary state changes. It would be after all the steps on this slide that the other processor B could make its request and possibly cause A to send its value or flush to L3 or memory.
@jmc, Oh! so would you say that the state change from S/M to Invalid happens independently of the value being flushed to memory. The reason I find it to be confusing is that I feel if the flush does not happen, though future requests from other processors could feel that they have the latest data, but they might not.
@paracon I think I may have misunderstood your question. I took it to be asking about whether processor A flushes its value at step 4, but now I see that it makes more sense for you to be asking whether B flushes at step 4. Yes, B will indeed flush to L3/memory (if it has a modified value of X, which can only be true if it's in state M) when it snoops A's request in step 4 because that is part of the transition procedure when you receive a BusRd or BusRdX message from another processor.
The write commits after step 4, even though R0 technically still hasn't been written into the cache line until step 6, the other processors have snooped the request and thinks that it has.
It is important to know the distinction between effectively writing the line( the new value is now on the cache), and write committing the line:
In simple terms:
Write commit: The rest of the processors having that line, have enough information at this point about the line state, so that they will EVENTUALLY (not necessarily at this moment) read the new result when reading the line.