Path: utzoo!attcan!uunet!bellcore!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!uw-beaver!cornell!ken
From: ken@gvax.cs.cornell.edu (Ken Birman)
Newsgroups: comp.sys.isis
Subject: Re: Fast causal multicast
Message-ID: <48414@cornell.UUCP>
Date: 15 Nov 90 14:48:18 GMT
Sender: nobody@cornell.UUCP
Reply-To: ken@cs.cornell.edu (Ken Birman)
Distribution: comp
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 64

(From: scott@amethyst.omg.ORG (Scott Meyer))
(Subject: fast causal multicast)

>  > It is [...] my contention that [...]
>  > the application developer must EXPLICITLY handle this relationship [...]
>
>  I see this as being at odds with the OO paradigm, which says that you
>  generally don't know how things you call were implemented.  How can I
>  be explicit about preserving properties for a subsystem whose
>  implementation is a black box to me?

I'm not exposing the implementation of the things I call.  I am trying
to make explicit the implementation of the call itself (how messages
are delivered) - something that most OOL designers seem have left
rather vague.  Each subsystem remains completely opaque.  Subsystems
are accessed through a heirarchical structure that allows the developer
to make strong (synchronous) guarantees about how the subsystems will
interact, *when necessary*.  Now, it is true that a naive application
of heirarchical PGs will lead to a system with excessive synchrony,
however the availability of HPGs does not preclude the use of
basic cleverness.  To reconsider your database example, an
implementation allowing a greater degree of synchrony, would have
the database server send back a ticket associated with the request.
This ticket would then be passed to other processes that might
depend on the associated update having taken place.

>  Here, you are basically saying that this whole issue is because I
>  believe in asynchronous communication and you believe in a more
>  synchronized approach.

I'm not sure that we're so far apart.  As you point out with your
examples, completely asychronous systems are problematic.  The
question is how to introduce just enough synchrony to make a
fundamentally asynchronous system easy to reason about.  Excessive
synchrony is a fundamental performance problem (Von Neuman bottleneck).
 
>  Well, ISIS users do it all the time.

I think it's fair to say that ISIS users are as a whole considerably
more knowledgable about concurrent programming than are, say, PC
applications developers or MIS programmers (the people who use the
software that Netwise sells).  As I understand it, ISIS currently
allows a knowledgable programmer to implement a solution to your
database/blackboard example problems.  ISIS itself cannot detect or
prevent the occurrence of such a problem.  When you implement you fast
CBCAST protocol (ISIS 2.0?) ISIS will be able to prevent that problem
but at the cost of unnecessary synchrony (how much depends on how
frequently processes are members of more than one PG.)  If you then
implement your causality class solution, it would seem that you are
back where you started: no excessive synchrony but no
detection/prevention of concurrency problems.  Forgive me, but I'm
still skeptical that you can deliver a free lunch here...

My inclination is to try and present a single, simple mechanism for
introducing various degrees of synchrony (PG + Broadcast protocol) that
will allow distributed systems developers to create an initial system
quite rapidly by making use of fairly gross synchrony requirements.
After the system is running, performance can be increased (if
necessary) by relaxing synchrony requirements, replacing HPGs with
synchronization mechanisms specifically tailored to the application.

Regards,

--Scott