I'm confused on what the BusUpg signal is...I feel like we didn't see it on any of the diagrams.
rbandlam
Yes, we did not use BusUpg signal as such in any of the diagrams in earlier lectures but idea is as below:
When any processor has a cache hit on a line and if it is shared state, it has to inform other processors that i am going to write into this line, so invalidate your cache. BusUpg causes calling processor cache line state to change from shared to modified and other processor cache line state to invalid.
kayvonf
Good question. I see how this is not clear.
BusUpg is movement from the S state to the M state in the MSI/MESI protocols. It is exactly like a BusRdX, but memory need not respond with data. (Since the cache already has the line, albeit in the wrong state.) This behavior is in contrast to that of to BusRdX which technically involves not only the line state change but memory or another cache responding with the data for the line.
To keep things simple we didn't clarify this distinction before. So the BusRdX transaction on the S to M transition on this MSI diagram or this MESI diagram can really by thought of as a "line upgrade". Data need not be provided, only the line state changed.
kayvonf
I want to see someone explain why this is a race condition.
uncreative
It seems to me that this is a race condition because this sequence of actions allows P2 to issue a BusUpg when it should be in the invalid state.
When P1 wins the bus, P2 should be forced to drop down to the invalid state, and should have to issue a BusRdX to obtain the data in the modified state.
However, since it has an outstanding BusUpg which it is unable to cancel, P2 effectively issues a BusUpg as if it was in the Shared state. This will cause P1 to flush its write and drop to the invalid state, but P2 will never try to read P1's modification, since it believes that it is in the shared state.
This violates Cache Coherence, since P2 never observes the write from P1.
Faust
@uncreative, I think you are correct. From what I understand, P1 and P2 want to issue a bus upgrade. When P1 wins bus access and sends the bus upgrade. At this point P2 is still waiting for bus access. However, when it sees P1's BusUpg, drops its line into the invalid state. However, this causes a problem when P2 gets bus access, it should no longer be giving the BusUpg request because its line has been dropped to the invalid state. Becuase the BusUpg command assumes movement from the S to M state, P2 will not observe the write from P1 because P1 will drop its line when it sees P2's BusUpg.
aznshodan
@Faust & @uncreative, referring to MESI state transition diagram, when P1 and P2 requests for BusUpg, P1 "wins" in this case and transitions from shared state to Modified state. P2 - which is waiting to send out its own request for BusUpg - receives BusUpg from P1 and invalidates its line and drops to Invalid state. However, the pending request is still BusUpg which can't happen at Invalid state.
Is there a queue or an arbiter that handles all the bus commands - such as BusUpg, BusRd, BusRdx?
I'm confused on what the BusUpg signal is...I feel like we didn't see it on any of the diagrams.
Yes, we did not use BusUpg signal as such in any of the diagrams in earlier lectures but idea is as below:
When any processor has a cache hit on a line and if it is shared state, it has to inform other processors that i am going to write into this line, so invalidate your cache. BusUpg causes calling processor cache line state to change from shared to modified and other processor cache line state to invalid.
Good question. I see how this is not clear.
BusUpgis movement from the S state to the M state in the MSI/MESI protocols. It is exactly like aBusRdX, but memory need not respond with data. (Since the cache already has the line, albeit in the wrong state.) This behavior is in contrast to that of toBusRdXwhich technically involves not only the line state change but memory or another cache responding with the data for the line.To keep things simple we didn't clarify this distinction before. So the
BusRdXtransaction on the S to M transition on this MSI diagram or this MESI diagram can really by thought of as a "line upgrade". Data need not be provided, only the line state changed.I want to see someone explain why this is a race condition.
It seems to me that this is a race condition because this sequence of actions allows P2 to issue a BusUpg when it should be in the invalid state.
When P1 wins the bus, P2 should be forced to drop down to the invalid state, and should have to issue a BusRdX to obtain the data in the modified state.
However, since it has an outstanding BusUpg which it is unable to cancel, P2 effectively issues a BusUpg as if it was in the Shared state. This will cause P1 to flush its write and drop to the invalid state, but P2 will never try to read P1's modification, since it believes that it is in the shared state.
This violates Cache Coherence, since P2 never observes the write from P1.
@uncreative, I think you are correct. From what I understand, P1 and P2 want to issue a bus upgrade. When P1 wins bus access and sends the bus upgrade. At this point P2 is still waiting for bus access. However, when it sees P1's BusUpg, drops its line into the invalid state. However, this causes a problem when P2 gets bus access, it should no longer be giving the BusUpg request because its line has been dropped to the invalid state. Becuase the BusUpg command assumes movement from the S to M state, P2 will not observe the write from P1 because P1 will drop its line when it sees P2's BusUpg.
@Faust & @uncreative, referring to MESI state transition diagram, when P1 and P2 requests for BusUpg, P1 "wins" in this case and transitions from shared state to Modified state. P2 - which is waiting to send out its own request for BusUpg - receives BusUpg from P1 and invalidates its line and drops to Invalid state. However, the pending request is still BusUpg which can't happen at Invalid state.
Is there a queue or an arbiter that handles all the bus commands - such as BusUpg, BusRd, BusRdx?