Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!rpi!dali.cs.montana.edu!milton!uw-beaver!cornell!ken
From: ken@gvax.cs.cornell.edu (Ken Birman)
Newsgroups: comp.sys.isis
Subject: Re: Fast causal multicast
Message-ID: <48347@cornell.UUCP>
Date: 14 Nov 90 14:57:38 GMT
References: <48346@cornell.UUCP>
Sender: nobody@cornell.UUCP
Reply-To: ken@gvax.cs.cornell.edu (Ken Birman)
Distribution: comp
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 66

In article <48346@cornell.UUCP> scott@amethyst.omg.ORG writes:

> 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 see this problem as a general concurrency problem, rather than
> a distributed system problem.  A concurrent programer faced with such
> a problem would use some sort of MUTEX mechanism to ensure that
> the causal relationship between the two processes is respected.

Here, you are basically saying that this whole issue is because I believe
in asynchronous communication and you believe in a more synchronized 
approach.  Well, this is exactly what I would have expected: if the system
doesn't enforce causality in an automatic way, you just can take advantage
of asynchronous computation...

The Strom/Yemeni work and the recent follow-on is for a fairly restrictive
model: it can't support concurrent threads in one address space (well, it
can with a lot of limits on scheduling, but you lose a lot of flexibility
as a programmer in order to let them log information whenever a non-
deterministic event occurs).  So, yes, the model they use is nice, but no,
I don't see this as solving the same problem...

> [..].  However, I dispute the assumption [..] that the benefits of
> concurrency (or any other stye of programming) may be obtained "for
> free" - ie.  that [...] J. Random Hacker may write generally useful
> concurrent programs [...]

Well, ISIS users do it all the time.  

> [... re: causality classes] ... Here is the crux of our discussion...

What we have in mind is pretty simple compared to your suggestion.  Basically,
a system call sequence:
		SetDefaultCausalClass(unique-identifier);
		    create groups....
                ResetDefaultCausalClass();
would do the trick (you just keep track of the value on a per-thread basis).
There is no causality graph or anything.  The result is that each group
is in some class, and the system then enforces causality for groups in the
same class.

> Something must know about the physical topology of the network...

I agree with this.  We need to get information like this into Mach and Chorus
if we expect to put systems like ISIS (or Netwise) over these general 
frameworks and still benefit from special hardware.  I think it could be
largely automated.

> Speaking of threads.  How does Isis handle non-kernel threads?

We use a non-blocking IO library of our own.  There seems to be no major
performance penality, at least in our applications.  The system can do about
10,000 light weight context-switches per second on a Sparc 1 or SUN 3/60,
and the cost is one select system call amortized over multiple users,
plus two context-switches per call to "isis_select", our lightweight interface.
We also found SUN lwp slow (and big) and we no longer link it in by default.
However, in fairness to SUN, lwp also has a lot of mechanism that ISIS doesn't
use...

Ken