[cpp-threads] Yet another visibility question

[Paul E. McKenney]

On Wed, Jan 10, 2007 at 01:35:05PM -0800, Lawrence Crowl wrote:
> My concern with fences is the implication for distributed memory.
> With the current approach, the communication channel is both
> obvious and pairwise.  In contrast, fences are a global act, and
> physics does not like those.

When you say "distributed memory", do you mean NUMA architectures
or software distributed shared memory (e.g., use of MMU tricks
to support an illusion of shared memory among independent computers
connected via a high-speed network)?

In the NUMA case, there are a quite a few counter-examples to your
assertion.  In the DSM case, the implementations of which I am aware
permit a given page to be writeable only on one machine at a time,
and thus also have no problem with fences.

So, what do you mean by "distributed memory", and can you give an
explicit sequence of events supporting your assertion?

							Thanx, Paul

> On 1/10/07, Hans Boehm <Hans.Boehm at hp.com> wrote:
> >Let me see if I can summarize where I think we might stand.  (I'm a little
> >confused ...)
> >
> >A number of us think that high-level atomics, ideally with sequentially
> >consistent semantics and similar to Java volatiles, are highly desirable,
> >since they are the closest to actually being usable by mere mortals,
> >and give tolerable performance for things like double-checked locking.
> >(I think there was, and still is, a fairly clear concensus supporting this
> >on the C++ committee.)
> >
> >I would really prefer a model in which programs that use high-level
> >atomics to synchronize, and have no races on ordinary variables, behave
> >sequentially consistently.  (I think the hard part of this on the
> >implementation side is actually getting sequential consistency for
> >programs that use only atomics.)  This implies that high-level atomics
> >have acquire/release semantics (in addition to satisfying other
> >requirements).
> >
> >At least Herb doesn't think anything at a lower level is useful.
> >But my impression from past committee meetings is that most people also
> >want a lower layer.  The alternative would be to try to capture
> >all the interesting use cases in more specialized libraries instead.
> >
> >I still think any lower layer should be based primarily on acquire/release
> >ordering constraints rather than explicit fences.  This gives us some
> >consistency with the high layer, reasonable performance on X86, etc.
> >I'm not sure whether anyone meant to disagree with this.  In any case,
> >I don't think I've seen anything like a complete proposal that doesn't
> >go this route.
> >
> >I think we should, as much as we possibly can, avoid saying anything
> >about dependencies.  I still have no idea how to define them.  And all
> >our past attempts impose nasty nonlocal optimization constraints.
> >
> >I think we agree that there are cases in which you can get better
> >code by allowing explicit fences, mostly because we currently have no
> >other way of expressing conditional ordering constraints.  If we do
> >add explicit fences, the SPARC model seems to be a reasonable one
> >to follow, though the
> >
> >LoadStore | LoadLoad
> >
> >and
> >
> >StoreStore | LoadStore
> >
> >(essentially acquire and release replacement) variants are probably the
> >most interesting, and the real goal may be to be able to generate a
> >PowerPC-lwsync-like fence, which is essentially the union of these two.
> >
> >(Does the combined fence run appreciably slower on SPARC than the
> >two variants?)
> >
> >If we get to the question of adding explicit fences, my impression is that
> >opinions are strongly divided.  But I think that is essentially a
> >complexity vs. expressivity and performance trade-off.
> >
> >Hans
> >
> >--
> >cpp-threads mailing list
> >cpp-threads at decadentplace.org.uk
> >http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
> >
> 
> 
> --
> Lawrence Crowl
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads