Re: Questions about memory barriers

[Clemens Buchacher]

On Wed, Oct 13, 2004 at 11:25:30AM -0400, Alan Stern wrote:
> The impression I get from what you wrote below is that the barrier
> instruction causes the processor to abandon all speculative reads until
> any already-issued reads have completed.  Isn't that essentially the same
> as saying that no speculative (i.e., non-constant) read can be moved back
> past the barrier and that the barrier won't finish until all
> already-issued reads have completed (in other words, these reads can't be
> moved forward past the barrier)?

Well, first you have to invalidate any preceding speculative reads and, as you
correctly stated, abstain from any further speculative reads until all reads
preceding the barrier have completed. This restriction, however, does not force
us to wait at the barrier until all reads have completed (as a read barrier
would). We can continue to execute instructions for which all reads they depend
on have completed.

As a result, all read_barrier_depends() does is to prohibit reordering of
dependent instructions _across_ the barrier.

> This seems like a devilishly easy sort of thing to overlook!

True. Note that Alpha is the only architecture whose read_barrier_depends()
macro expands to something other than a no-op.

Clemens
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/