lkml.org 
[lkml]   [2006]   [Mar]   [16]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateThu, 16 Mar 2006 09:18:26 -0800 (PST)
FromLinus Torvalds <>
SubjectRe: [PATCH] Document Linux's memory barriers [try #5]
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