In class we talked about how the write commits when the processors agree and everyone acknowledges the intent to write. The write can complete later on though, and any subsequent actions are cache misses because everyone has dropped the line. Because we assumed that the bus was an atomic process, we can also say that it occurs when we gain access to the bus for this part of the lecture.
I'm still a little confused by why the write back buffer does not affect the time of commit.
Black
Can we assume that write back buffer is transparent to read, write operation?
jhibshma
@makingthingsfast, I think everything you said about the definition of the time of the commit is correct. In your definition, you made no reference to the buffer, which suggests the buffer is not relevant to commit time. A write-back buffer is used when data is taken from the cache and written back into a lower level of memory, this occurs some time after the processor has written a new value to its cache line which is in turn after the commit.
huehue
What exactly is meant by "commit" and "complete" in this case?
ZhuansunXt
@huehue, Commit means the write is announced and acknowledged by other caches. This is important since it relates to the this write's global sequential order that is observed in the system; Complete means that the data is physically written to the cache line. This time defer is due to transactions are not atomic (although we assume bus is atomic). It's like you 'commit' your push on Github and this push is completed when the code is actually updated on your repo (Bad example?).
418_touhenying
@ZhuansunXt Why is it that "This time defer is due to transactions are not atomic (although we assume bus is atomic)"?
Is it that after a processor declares a cache line as M state, it can actually write to that cache line later? This happens within the processor and its own cache, and I think the bus in this case is not involved?
yikesaiting
To answer the question why write buffer does not effect. I think it is because there is protocol ensuring write buffer provides latest version of data if data is required by other caches. Thus, we can view write being commit even it is written to the write buffer.
illuminated
A line is only added to the write-back buffer if a node had the line in the M state. All other nodes would have acknowledged this request, meaning the transaction is considered to be committed.
The snoop controller is responsible for checking the write-back buffer in addition to the cache because there may be outstanding bus access requests here. If this happens, the modified line is sent back and the request is cancelled (based on slide 35 from this presentation). This does not affect a commit because, as noted above, if a line is in the write-back buffer it is already committed.
rds
The Write-Back buffer comes into the picture when a dirty cache line is to be flushed (i.e. there's a request to read/write to a line in the M state). When a read-exclusive transaction appears on the bus and once the write immediately commits, this cache line will be loaded into the cache in the 'M' state. Previously, it could have been in either the 'S' or the 'M' state (in which case, the data would be stored in the write-back buffer to be later flushed out to memory). The write commits when all processors have acknowledged the read-exclusive transaction regardless of whether data needed to flushed out to memory or not.
In class we talked about how the write commits when the processors agree and everyone acknowledges the intent to write. The write can complete later on though, and any subsequent actions are cache misses because everyone has dropped the line. Because we assumed that the bus was an atomic process, we can also say that it occurs when we gain access to the bus for this part of the lecture.
I'm still a little confused by why the write back buffer does not affect the time of commit.
Can we assume that write back buffer is transparent to read, write operation?
@makingthingsfast, I think everything you said about the definition of the time of the commit is correct. In your definition, you made no reference to the buffer, which suggests the buffer is not relevant to commit time. A write-back buffer is used when data is taken from the cache and written back into a lower level of memory, this occurs some time after the processor has written a new value to its cache line which is in turn after the commit.
What exactly is meant by "commit" and "complete" in this case?
@huehue, Commit means the write is announced and acknowledged by other caches. This is important since it relates to the this write's global sequential order that is observed in the system; Complete means that the data is physically written to the cache line. This time defer is due to transactions are not atomic (although we assume bus is atomic). It's like you 'commit' your push on Github and this push is completed when the code is actually updated on your repo (Bad example?).
@ZhuansunXt Why is it that "This time defer is due to transactions are not atomic (although we assume bus is atomic)"?
Is it that after a processor declares a cache line as M state, it can actually write to that cache line later? This happens within the processor and its own cache, and I think the bus in this case is not involved?
To answer the question why write buffer does not effect. I think it is because there is protocol ensuring write buffer provides latest version of data if data is required by other caches. Thus, we can view write being commit even it is written to the write buffer.
A line is only added to the write-back buffer if a node had the line in the M state. All other nodes would have acknowledged this request, meaning the transaction is considered to be committed.
The snoop controller is responsible for checking the write-back buffer in addition to the cache because there may be outstanding bus access requests here. If this happens, the modified line is sent back and the request is cancelled (based on slide 35 from this presentation). This does not affect a commit because, as noted above, if a line is in the write-back buffer it is already committed.
The Write-Back buffer comes into the picture when a dirty cache line is to be flushed (i.e. there's a request to read/write to a line in the M state). When a read-exclusive transaction appears on the bus and once the write immediately commits, this cache line will be loaded into the cache in the 'M' state. Previously, it could have been in either the 'S' or the 'M' state (in which case, the data would be stored in the write-back buffer to be later flushed out to memory). The write commits when all processors have acknowledged the read-exclusive transaction regardless of whether data needed to flushed out to memory or not.