Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!ken
From: ken@gvax.cs.cornell.edu (Ken Birman)
Newsgroups: comp.sys.isis
Subject: Re: Re: ISIS "homework" problem
Message-ID: <35821@cornell.UUCP>
Date: 9 Jan 90 16:36:15 GMT
References: <35282@cornell.UUCP> <6860001@aspen.IAG.HP.COM>
Sender: nobody@cornell.UUCP
Reply-To: ken@gvax.cs.cornell.edu (Ken Birman)
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 25

In article <6860001@aspen.IAG.HP.COM> laubach@aspen.IAG.HP.COM
    (Mark Laubach) writes:
>MEMNET, as published, has no connection with CMU as I know it.
>

I wonder if Stan might not have had Kung's work on Nectar and Iwarp in
mind.  This is a high speed optical interconnect; it is so fast that
it makes paging off of remote machines over a network blaze in 
comparison with reading from a disk. This definitely does argue for
a shared memory abstraction.  DEC SRC has a similar interconnect.

It seems relevant that when Kung talks about this, he tends to say that
software for controlling complex distributed applications with replicated
data is the big obstacle, not hardware.  The problem he sees is that
the set of programs sharing the memory changes dynamically and the 
big picture is hence a very complex and very dynamic one, which presumably
has to be fault-tolerant too.  And, viewed from his perspective, the
technology for controlling this mess is lagging way behgind the hardware.

We need an effective technology for distributed control and consistency
if we are to support facilities like this sort of shared memory in a robust
way.  Even if everyone programs using the resulting shared objects, 
someone needs to implement it...  In effect, shared objects become yet
another "tool" in our bag of tools; the underlying issues are hidden but
still relevant.