Messages in this thread | | | From | David Mosberger <> | Date | Mon, 13 May 2002 09:36:29 -0700 | Subject | Re: Memory Barrier Definitions |
| |
>>>>> On Mon, 13 May 2002 13:26:05 +1000, Rusty Russell <rusty@rustcorp.com.au> said:
Rusty> OK. So ignoring the fact that you somehow have to attach Rusty> your barriers to a load or store for the moment, we have Rusty> before vs. after (ia64), read vs. write (most archs), io vs Rusty> mem (ppc, ppc64), data dependency vs non-data dependency Rusty> (alpha), and smp vs up.
An alternative way to think about the ia64 model is that it provides "ordering" variables. Accesses to those variables won't be reordered by the compiler or the CPU and also order other (normally unordered accesses). One way to support this is have an ORDERING attribute for variables (which would expand into "volatile" on ia64). This would have to be complemented by a set of barrier routines which will achieve the desired ordering on machines that don't have the acquire/release model of ia64 (and on ia64, they would expand into nothing).
--david - 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/
| |