Messages in this thread | | | Date | Wed, 13 Oct 2004 19:03:14 +0200 | From | Clemens Buchacher <> | Subject | Re: Questions about memory barriers |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |