In the case where write buffers are used, it is now totally possible for there to be a situation where r1 = r2 = 0. In particular, this would happen if Proc 0 put "A = 1" in its write buffer and Proc1 put "B = 1" in its write buffer, and then both proceeded to do their subsequent read from A/B before the contents of the write buffer were actually emptied and applied to the state of memory. By overlapping the execution of reads and writes to improve memory latency, these systems have also introduced data races that result in memory inconsistency here.

In the scenario on slide 31, the two instructions don't conflict so there is no need to wait for the write to finish. We have the same situation here where A = 0 and B = 0 can be stored in memory despite setting A = 1 and B = 1. Even though this is counterintuitive, it provides speedups by hiding writing latencies. If we wanted to ensure that A = 1 and B = 1 is written to memory instead, we would need to use sequential consistency or a synchronisation call.

Is this a case where we would need cache coherence protocols? Write buffers look like caches and the writes need to be put back in memory before another read to the same thing happens.

@haiyuem I think the buffers are used to hide the latency of not just the write but also the overhead of the coherence protocol. I would assume that the coherence protocol work is done by the cache controller though, which is why the processor can just move on once the write is enqueued, but I'm not at all sure.

Actually, if that ^ is the case, why do we need write buffers in the first place? Other than possible data dependencies, why would the processor need/want to stall after issuing the write? I guess this is because my knowledge of how the write actually happens is hazy, but I would assume that once we have calculated a destination address, etc., there is some external module which holds/directs the data to each subsequent cache on misses, and coordinates with the directory to manage the status of the entry. (This is kind of starting to sound like a queue + some control logic, but if that is in fact why we had the queue, what happens when we don't?)

^ Good question, I'm confused about that too. I think one possible reason to have buffers other than data dependencies is to handle multiple writes, just like the queue you mentioned.

One much simpler reason that just came to mind is that if you have a separate buffer for the writes, you can let the read go first, like bypassing cars on a highway. I guess this doesn't do anything to directly hide latency, but if this allows you to further do a bunch of computation on that value, I think that is where the latency hiding might arise. Otherwise, I think the write buffer itself would need to provide some form of parallelism wrt the memory transactions themselves.

I recall in EE180 that in some architectures, the write buffer can be checked for updates before going to memory, which in those architectures would probably this type of w-r consistency issues