3 ms·

The question is, why are we dealing with cross-core cache invalidation at all. When core A writes to memory location X, then core B reads from memory location X

The question is, why are we dealing with cross-core cache invalidation at all. When core A writes to memory location X, then core B reads from memory location X, why do we insist that core B reads what core A wrote? Almost by definition, the only reason to make such a requirement is that we want to use main memory as a mechanism to communicate between cores. An alternative architecture would be to say that different cores should not be using the same region of memory. If they attempt to do so, it is an error and exactly what happens is undefined. We only need to worry about cache invalidation when we transfer ownership of a region of memory between cores. If we had a non memory method of cross core communication, we would need to pass memory between cores far less often, which would greatly simplyfy the problem of memory cache invaldiation.

yuliyp 6y ago
> the only reason to make such a requirement is that we want to use main memory as a mechanism to communicate between cores. For a very liberal definition of "communicate" that statement is true. The only reason for multiple threads to be sharing an address space is if they mutually depend on how the others are interacting with the data in there. The reason for cross-core cache invalidation is that otherwise it becomes impossible to reason about behavior of any data structures written and read by different threads. Imagine trying to build multiple consumer queue without any cache coherence protocols.
saagarjha 6y ago
> When core A writes to memory location X, then core B reads from memory location X, why do we insist that core B reads what core A wrote? Well, on many platforms we don't necessarily require this to be true immediately.
pjc50 6y ago
> When core A writes to memory location X, then core B reads from memory location X, why do we insist that core B reads what core A wrote? Because that's what the Intel programmer's model of memory specifies. This is not necessarily true on ARM: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/memory-access-ordering-part-3---memory-access-ordering-in-the-arm-architecture https://community.arm.com/developer/ip-products/processors/b... > different cores should not be using the same region of memory Generally known as "NUMA"; this is a viable programmer's model, but it's different from what people are used to, and requires either software changes or a lot of performance-impacting compatibility layers when software accesses pre-existing global variables. (You could certainly get NUMA multiprocessing systems back in the day - to make effective use you had to pin processes to cores, because the cost of migrating memory about was considerable otherwise)

yuliyp 6y ago

> the only reason to make such a requirement is that we want to use main memory as a mechanism to communicate between cores. For a very liberal definition of "communicate" that statement is true. The only reason for multiple threads to be sharing an address space is if they mutually depend on how the others are interacting with the data in there. The reason for cross-core cache invalidation is that otherwise it becomes impossible to reason about behavior of any data structures written and read by different threads. Imagine trying to build multiple consumer queue without any cache coherence protocols.

saagarjha 6y ago

> When core A writes to memory location X, then core B reads from memory location X, why do we insist that core B reads what core A wrote? Well, on many platforms we don't necessarily require this to be true immediately.

pjc50 6y ago

> When core A writes to memory location X, then core B reads from memory location X, why do we insist that core B reads what core A wrote? Because that's what the Intel programmer's model of memory specifies. This is not necessarily true on ARM: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/memory-access-ordering-part-3---memory-access-ordering-in-the-arm-architecture https://community.arm.com/developer/ip-products/processors/b... > different cores should not be using the same region of memory Generally known as "NUMA"; this is a viable programmer's model, but it's different from what people are used to, and requires either software changes or a lot of performance-impacting compatibility layers when software accesses pre-existing global variables. (You could certainly get NUMA multiprocessing systems back in the day - to make effective use you had to pin processes to cores, because the cost of migrating memory about was considerable otherwise)