Re: Synchronizing Bit operations V2

[Hans Boehm]

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
>
-
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/