I would argue that there are two semi-viable approaches to this: 1) Guarantee that all atomic operations always include a full memory fence/barrier. That way the programmer can largely ignore associated memory ordering issues. 2) Make the ordering semantics as explicit and clean as possible, which is being proposed here. It seems to me that anything in the middle doesn't work well. If programmers have to think about ordering at all, you want to make it as difficult as possible to overlook. My impression is that approach (1) tends not to stick, since it involves a substantial performance hit on architectures on which the fence is not implicitly included in atomic operations. Those include Itanium and PowerPC. Hans On Fri, 31 Mar 2006, Andi Kleen wrote: > Christoph Lameter <clameter@xxxxxxx> writes: > > MODE_BARRIER > > An atomic operation that is guaranteed to occur between > > previous and later memory operations. > > > I think it's a bad idea to create such an complicated interface. > The chances that an average kernel coder will get these right are > quite small. And it will be 100% untested outside IA64 I guess > and thus likely be always slightly buggy as kernel code continues > to change. > > -Andi > - : send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
![]() |