![]() | |||||||||||||
Messages in this thread |
On Thu, 16 Mar 2006, David Howells wrote: > > More or less, I think; but Nick has raised a good point about whether I should > be mentioning the existence of things like caching at all in the document, > except to say that memory barriers can't be assumed to have any effect on them. > > The problem is that if I don't mention caches, I get lots of arguments about > the effects locking primitives have (since in modern CPUs these happen within > the caches and not much within memory). I can't just say these things affect > memory because it's just not necessarily true:-/ Well, the argument I have against mentioning caches is that cache coherency order is _not_ the only thing that is relevant. As already mentioned, data speculation can cause exactly the same "non-causal" effect as cache update ordering, so from a _conceptual_ standpoint, the cache is really just one implementation detail in the much bigger picture of buffering and speculative work re-ordering operations... So it might be a good idea to first explain the memory barriers in a more abstract sense without talking about what exactly goes on, and then have the section that gives _examples_ of what the CPU actually is doing that causes these barriers to be needed. And make it clear that the examples are just that - examples. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-03-16 18:21 [from the cache] ©2003-2008 | |||||||||||||