I’m not a processor design expert, but I’ve read a few articles about caches and cache coherency similar to this. If you were to make the mistake in an online conversation of implying that caches of different processor cores could be inconsistent or that, for example, volatile variables bypass cache you’d probably get someone point you at such an article. They’re not wrong, but they’re also not necessarily helpful. This one is better than most, I think, because it’s not being elitist.
In concurrency, correctness is hard enough without worrying about performance of the underlying hardware. While ‘volatile’ in Java might not truly need to write data through to core memory every time the variable is assigned, this mental model is very useful for reasoning about when volatile is necessary. If we think of each processor core having incoherent caches, and various primitives (such as volatile) providing a way to force read/writes to go via the shared core memory, we have a much more straightforward way of understanding the whole issue, even if it’s not accurate at the architectural level.
This article, in fact, glosses over store buffers, which in fact have a similar function to a cache but on some architectures (including even x86 in certain usually-avoided conditions, IIUC) can be incoherent; the conclusion - that from the perspective of the software application, the memory subsystem appears to be a single, consistent, monolith - is arguably not entirely correct; however, the point it’s making is really about the performance side - if we use the mental model I’ve described (which many do, I suspect because it is far more straight-forward to understand than the truth) we might believe that these synchronisation primitives are very costly, when in fact they may not be so. That’s a valid point.
I’m not a processor design expert, but I’ve read a few articles about caches and cache coherency similar to this. If you were to make the mistake in an online conversation of implying that caches of different processor cores could be inconsistent or that, for example, volatile variables bypass cache you’d probably get someone point you at such an article. They’re not wrong, but they’re also not necessarily helpful. This one is better than most, I think, because it’s not being elitist.
In concurrency, correctness is hard enough without worrying about performance of the underlying hardware. While ‘volatile’ in Java might not truly need to write data through to core memory every time the variable is assigned, this mental model is very useful for reasoning about when volatile is necessary. If we think of each processor core having incoherent caches, and various primitives (such as volatile) providing a way to force read/writes to go via the shared core memory, we have a much more straightforward way of understanding the whole issue, even if it’s not accurate at the architectural level.
This article, in fact, glosses over store buffers, which in fact have a similar function to a cache but on some architectures (including even x86 in certain usually-avoided conditions, IIUC) can be incoherent; the conclusion - that from the perspective of the software application, the memory subsystem appears to be a single, consistent, monolith - is arguably not entirely correct; however, the point it’s making is really about the performance side - if we use the mental model I’ve described (which many do, I suspect because it is far more straight-forward to understand than the truth) we might believe that these synchronisation primitives are very costly, when in fact they may not be so. That’s a valid point.