From: retrac@medea.cs.rice.edu (John Carter)
Subject: Re: IBM's FIRST RISC System/6000(tm) based Shared Memory Parallel Processor
Keywords: mp shared-memory parallel multiprocessor risc smp
Organization: Rice University, Houston
Date: Fri, 11 Dec 1992 19:53:51 GMT

In article <lifvl6INNan3@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes:
>
>I've had this nagging suspicion for about a year that people building
>MP's were working awfully hard to maintain coherency where it just
>didn't matter.  Given that most of the programming languages tell you
>to lock your data if it is shared, the "we're guarding against this"
>examples always looked like buggy programs to me.  People have been
>working on this at Rice, I know, and at least one other place that I
>cannot recall right now.

There's been quite a bit of work on relaxed forms of consistency that
"force" programmers to use appropriate synchronization (locks,
barriers, whatever) to ensure correctness, and in return promise to
significantly reduce the amount of unnecessary communications imposed
by the sequential consistency (or "strong" consistency) model.  Some
examples are the work on weak consistency done at USC by Scheurich and
Dubois and the work on release consistency from Stanford's DASH
project by Gharachorloo, et al.  Note that the Alpha incorporates
hooks to support relaxed consistency models.  This is far from new
stuff, at least in the research community.  Expect the next generation
of shared memory multiprocessors (at least the ones larger than four
or so processors) to incorporate these ideas.

>		Data Merging for Shared-Memory Multiprocessors
>		---------------------------------------------
>			    <person working at>, IBM
>
>We describe an efficient software cache consistency mechanism for shared
>memory multiprocessors that supports multiple writers and works for
>cache lines of any size.  Our mechanism relies on the fact that, for a
>correct program, only the global memory needs a consistent view of the
>shared data between synchronization points.  Our delayed consistency
>mechanism allows arbitrary use of data blocks between synchronizations.

Sounds like something I published at SOSP (Symposium on Operating
Systems Principles) last year.  The write-shared protocol of the Munin
distributed shared memory system supports multiple concurrent writers
to the same block of data (page or object, depending on how you're
looking at things).  Munin uses as its memory model the release
consistency model, although it uses it in a novel way to support the
delaying and merging of updates and thus allow multiple concurrent
writers to shared data.  Does wonders towards eliminating the effects
of false sharing.

For details on the write-shared and other protocols of Munin, you can
look in the proceedings of the 13th SOSP for "Implementation and
Performance of Munin".  More details and a lot more performance
numbers are in my dissertation, which will be available within a
month.

[I doubt that I am the person at Rice to whom David was referring.
The compiler group has started looking into these issues as well.]

-- 
John Carter  -*-  Rice University Computer Systems Lab  -*-  retrac@rice.edu

Thesis hacking Owl, soon to be Ute.  Move over Salt Lake, here he comes!
Xref: sparky comp.arch:11706 comp.sys.intel:2735