HDTenEightyP/NetNews huggingface dataset:
From: dfk@dartmouth.edu (David Kotz)
Newsgroups: comp.os.research
Subject: Re: Async comm. vs RPC (was Re: Have we....)
Date: 14 Apr 92 14:31:34 GMT
Article-I.D.: darkstar.32993
Organization: Dartmouth College, Hanover, NH
Originator: osr@ftp


In article <32623@darkstar.ucsc.edu> jsloan@ncar.ucar.edu (John Sloan) writes:
>    From article <32505@darkstar.ucsc.edu>, by pete@medea.rice.edu (Louis Wu):
>    Status: R
> 
>  > If the RPC returns information that is *not* needed immediately, there are
>  > two ways to get performance comparable to async communication:
> 	   :
>  > 	2) Futures
> 
>    I'm assuming this is RPC with lazy evaluation. In general, I think RPC
>    would be more acceptable if implemented in (for example) a functional
>    language with lazy evaluation. This produces implicit asynchronous
>    messaging, allowing a thread to continue unblocked until the result
>    from the RPC function is really required. Need idea.

Yes, indeed. For an example, see the nifty Mentat programming
language. It essentially does this, though in Mentat they use object
invocation instead of RPC.  Similar ideas.

@TechReport{grimshaw:mentat,
  author = 	"Andrew S. Grimshaw",
  title = 	"An Introduction to Parallel Object-Oriented
			  Programming with {Mentat}",
  institution = 	"University of Virginia Computer Science",
  year = 	1991,
  number = 	"TR-91-07",
  comment = "A parallel language based on C++. Course-grain dataflow is
handled by the compiler, so that the results of one call are computed
asynchronously, only blocking the caller when the results are used
locally, possibly much later. If the caller only uses them as
arguments to other methods, then the results of the first are passed
on to the second, bypassing the caller entirely. Runs on Sun3, BBN,
and iPSC/860. Available for ftp. See grimshaw@uvacs.cs.virginia.edu",
  keyword = "parallel programming, programming language,
			  object-oriented, dataflow"
}

David Kotz
--
-----------------
Mathematics and Computer Science
Dartmouth College, 6188 Bradley Hall, Hanover NH 03755-3551
email: David.Kotz@Dartmouth.edu    or   dfk@cs.dartmouth.edu
From: crispin@csd.uwo.ca (Crispin Cowan)
Subject: Re: A challenge
Organization: Department of Computer Science, University of Western Ontario, London
Date: Fri, 10 Apr 1992 17:37:04 GMT

In article <32507@darkstar.ucsc.edu> ast@cs.vu.nl (Andy Tanenbaum) writes:
>Instead,
>for the second act, I hereby challenge all the people who have commented
>on my list to do better.
Ok, taking up the challenge:

1.  We have invented a whole bunch of interesting new computing
    paradigms, including but not limited to Andy's Top Five list.

2.  We have evolved better and better ways to implement these paradigms.

3.  We CANNOT agree on which of them in competing circumstances is best.
    This is the jist of my smart-ass comment about "have to plug your
    own system."  The fact that so many of the leaders of this field
    felt it necessary to weigh in and argue that their favourite
    paradigm was better than the other guy's CLEARLY indicates that
    there is no such agreement on these issues.

The true intent of Andy's question was "Have we settled on anything
being an *optimal* way to do thing X?"  I suggest that there are very
few such answers.  A Few that I can think of:

1.  We can do a lot more with compilers than we thought.  RISC is the
    result.  Perhaps we can do more, esp. WRT distributed systems.

2.  Source-level compatability is a way to get portability across
    architectures.  This was the lesson of UNIX, and it has been proven
    in practice over the years.  NOTE:  this was only made possible
    because a lot of the issues of imperitive programming languages for
    local processing were settled, and we *could* pick a few stable
    languages (C, Pascal, and later Ada, etc.) to use as our portability
    framework.  We're NOT going to get such portability across
    distributed systems until we settle on a few distributed processing
    paradigms.

There may be a few other things that we can all agree on, that we didn't
know 20 years ago, and that aren't trivial, but not many.

>As you can see, all of my points relate to one theme: making it easier to
>build and use distributed systems.
Perhaps my comments also build towards a theme.  We know how to build
distributed systems, but we can't agree yet on which way is best, or
even what "best" means.

Crispin
-----
Crispin Cowan, CS grad student, University of Western Ontario
Phyz-mail:  Middlesex College, MC28-C, N6A 5B7
E-mail:     crispin@csd.uwo.ca		Voice:  519-661-3342 
"If you want an operating system that is full of vitality and has a
great future, use OS/2."  --Andy Tanenbaum
From: jsloan@ncar.ucar.edu (John Sloan)
Newsgroups: comp.os.research
Subject: Re: Async comm. vs RPC (was Re: Have we....)
Date: 10 Apr 92 18:04:50 GMT
Organization: Scientific Computing Division/NCAR Boulder, CO
Originator: osr@ftp

From article <32505@darkstar.ucsc.edu>, by pete@medea.rice.edu (Louis Wu):
Status: R

> If the RPC returns information that is *not* needed immediately, there are
> two ways to get performance comparable to async communication:
	:
> 	2) Futures

I'm assuming this is RPC with lazy evaluation. In general, I think RPC
would be more acceptable if implemented in (for example) a functional
language with lazy evaluation. This produces implicit asynchronous
messaging, allowing a thread to continue unblocked until the result
from the RPC function is really required. Need idea.

--
John Sloan              "Since I've given up hope,        +1 303 497 1243
NCAR/SCD                   I feel much better."       Fax +1 303 497 1137
Boulder CO 80307-3000 USA                            jsloan@ncar.ucar.edu
Logical Disclaimer:  belong(opinions,jsloan). belong(opinions,_):-!,fail.
From: Andy Tanenbaum <ast@cs.vu.nl>
Subject: Research position in operating systems in Amsterdam
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam
Date: Thu, 16 Apr 1992 15:45:56 GMT


I am looking for a person to join my group starting around January 1993 for
a year and a half or so (open to negotiation).  This is not a permanent
position, so it might be suitable for a recent Ph.D. (postdoc) or someone 
on sabbatical.

The ideal candidate would have interest in, and experience with, one or more
of the following research areas:

	- Distributed operating systems
	- Distributed shared memory
	- Wide-area distributed systems
	- Applications for distributed systems
	- Related area

The candidate would be expected to teach about one course per semester
(e.g., on computer networks), and supervise a few Masters' theses.  Masters'
students do programming related to the supervisor's research (= free
labor).  The rest of the time would be available for research on a mutually
agreed upon topic.  My group is very "systems" oriented.  Theorists need
not apply.

Much of our recent work relates to the Amoeba distributed operating
system, developed here in Amsterdam.  If you are not familiar with
Amoeba, two widely [available] papers are in the May 1990 IEEE Computer
Magazine (pp. 44-53), and the Dec. 1990 CACM (pp. 46-63).  Additional
papers are available by FTP from ftp.cs.vu.nl (192.31.231.42) in the
'amoeba' directory.

The department has an experimental Amoeba system consisting of 48 MC68030's,
soon to be augmented by a system with 128 high-performance CPUs.  These
machines are used exclusively by the researchers, their students, and the
Amoeba programmers.  For general computing, we are a Sun shop, with many 
SPARCstations, SPARC servers, etc.

The Vrije Universiteit is located in Amsterdam, The Netherlands.  Amsterdam
is a dynamic city, with many restaurants, museums, musical performances,
and other cultural activities.  The weather is similar to that of Seattle.
Public transit is excellent, so car is unnecessary, and virtually everyone 
speaks English.  It is a pleasant city to live in.

Applicants should send the following items (preferably by email in troff -ms
format):

   1. Curriculum vitae (name, address, nationality, marital status, degrees 
      with school, date, and major, programming experience, work experience, 
      etc.)

   2. List of publications, patents, awards, and similar items.

   3. The name and email address (or FAX number) of 3 professional references.

   4. A statement describing the kind of research you would like to do here,
      and how this relates to your background.

   5. Whether you would be coming with any additional persons.  This relates
      to getting residence and work permits, schooling, and the like.

For more information or to apply, contact me by email or FAX.  

	Andrew S. Tanenbaum
	Vrije Universiteit
	Dept. of Mathematics and Computer Science
	De Boelelaan 1081a
	1081 HV  Amsterdam
	The Netherlands

	Email: ast@cs.vu.nl
	Phone: +31 20 5485574 (secretary is: +31 20 5487273)
	Fax:   +31 20 6427705


Andy Tanenbaum
From: rminnich@super.super.org (Ronald G Minnich)
Newsgroups: comp.os.research
Subject: Re: Andy Tanenbaum hasn't learned anything
Date: 7 Apr 92 03:33:47 GMT
Organization: Supercomputing Research Center (Bowie, MD)
Originator: osr@ftp

In article <32234@darkstar.ucsc.edu> rob@alice.att.com (research!rob) writes:
>   - Distributed shared memory in one form or another is a convenient model
>	Convenient for whom?  This one baffles us: distributed shared memory
>	is a lousy model for building systems, yet everyone seems to be
>	doing it.  (Try to find a PhD this year on a different topic.)
Convenient for the poor shmucks, down in the trenches, who just 
want to get their distributed program running, and don't really like 
RPC/whatever-current-fad as their way of sharing data. 
What kind of systems is it lousy for? 
You have a specific reason for the 'lousy' claim?

ron
From: morin@irisa.fr (Christine Morin)
Newsgroups: comp.os.research
Subject: *** CFP 5th ACM SIGOPS European Workshop ***
Date: 9 Apr 92 14:44:10 GMT
Organization: IRISA, Rennes (Fr)
Originator: osr@ftp



			Call for Participation

		Fifth ACM SIGOPS European Workshop

	Models and Paradigms for Distributed Systems Structuring


			September 21-23, 1992
		     Le Mont Saint-Michel, France

			Organized by IRISA-INRIA


A significant body of experience in the design and implementation of
distributed operating systems has been developed in the last 15 years, both
through research prototypes and industrial products. The time seems to be
right for an attempt to formulate, to consolidate and to evaluate the main
models, concepts and paradigms on which the design of distributed operating
systems is based.

Examples of influential concepts are atomic transactions, atomic broadcast,
global time, order and causality, process groups, distributed shared memory,
etc. Examples of useful paradigms for structuring distributed systems are
object structures, client-server models, micro-kernel based architectures,
various forms of remote procedure call, etc.

This workshop should be the occasion for the distributed systems community to
take a global view of the main concepts on which their practice is based. We
should assess to which degree these concepts can help to design and build
systems that meet the requirements of efficiency, information sharing and
reliability imposed by the applications.

Contributions that emphasize the interplay between concepts and experience
will be specially appreciated.

Workshop attendance is limited to 50 people. The workshop will be held at the
historical site of Le Mont Saint-Michel, in Normandy. If you wish to
participate, please submit by April 17, 1992 a position paper of not more
than five pages. Please send seven copies of your position paper to the
Workshop Chairman:


Prof. Jean-Pierre Bana^tre
IRISA Campus universitaire de Beaulieu 35042 Rennes Cedex, France
Tel: (+33) 99 84 72 20
Fax: (+33) 99 38 38 32 
e-mail: jpbanatre@irisa.fr


Notification of acceptance will be mailed by May 30, 1992. Please include an
electronic mailing address (if you have one) in your position paper.
The workshop proceedings including all accepted papers will be published by
INRIA. We are also considering publishing revised versions of selected papers
in Operating Systems Review.


Program Committee
 
J.-P. Bana^tre, IRISA-INRIA, France (Chairman) 
S. Krakowiak, IMAG, France (Co-chairman) 
O. Babaoglu, Univ. Bologna, Italy 
A. Black, DEC CRL, USA 
K. Birman, Univ. Cornell, USA
S. Mullender, Univ. Twente, The Netherlands
M. Shapiro, INRIA, France
S. Shrivastava, Univ. Newcastle upon Tyne, UK

Organizing Committee

J.-P. Bana^tre, M. Bana^tre, C. Morin, G. Muller, IRISA-INRIA, France
From: henry@zoo.toronto.edu (Henry Spencer)
Newsgroups: comp.os.research
Subject: Re: Andy Tanenbaum hasn't learned anything
Date: 7 Apr 92 16:23:56 GMT
Article-I.D.: darkstar.32277
Organization: U of Toronto Zoology
Originator: osr@ftp

In article <32234@darkstar.ucsc.edu> rob@alice.att.com (research!rob) writes:
>   - Microkernels are the way to go
>	False unless your only goal is to get papers published...
>   - RPC is a good idea to base your system on
>	Depends on what you mean by RPC...
>   - Threads should be managed by the kernel, not in user space
>	Better: have a decent process model...

I'm reminded here of a recent piece from John Ousterhout in OSR, arguing
that the customers do not *want* wonderful new abstractions -- what they
want, mostly, is better implementations of the old ones.  Sounded good to me.
-- 
GCC 2.0 is to C as SVR4 is to Unix.     | Henry Spencer @ U of Toronto Zoology
                             -Dick Dunn |  henry@zoo.toronto.edu  utzoo!henry
From: stephen@estragon.uchicago.edu (Stephen P Spackman)
Newsgroups: comp.os.research
Subject: Re: Async comm. vs RPC (was Re: Have we....)
Date: 11 Apr 92 11:24:31 GMT
Article-I.D.: darkstar.32684
Organization: University of Chicago CILS
Originator: osr@ftp

In article <32623@darkstar.ucsc.edu> jsloan@ncar.ucar.edu (John Sloan) writes:
|I'm assuming this is RPC with lazy evaluation. In general, I think RPC
|would be more acceptable if implemented in (for example) a functional
|language with lazy evaluation. This produces implicit asynchronous
|messaging, allowing a thread to continue unblocked until the result
|from the RPC function is really required. Need idea.

I had planned to implement that here (we have a lazy-functional
language that we do full-text retrieval with - plug plug, a real
industrial-scale lazy-functional application!!!! Well, the database is
only a gig, to be honest, but it's an applicaiton that isn't a
compiler!).

The idea would be to let the user interface issue tree-structured
requests (not just sucking on a character stream) so that we can find
multiple "corners" at which to reduce, and then those can fire up
multiple "downward" i/o requests to the stored database. Even if this
just (a) exposed more read requests to the disk and (b) let us overlap
reductions with i/o, that would be a win, but (due to licensing
agreement foo) we actually do face the problem of having half the
database on a local CD and that other half across the internet at the
UofC, with all the latency THAT entails.

We aren't going to get to do it, though, because they're shutting the
centre down....
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------
From: stephen@estragon.uchicago.edu (Stephen P Spackman)
Newsgroups: comp.os.research
Subject: Re: assumptions of OS builders
Date: 9 Apr 92 02:52:56 GMT
Article-I.D.: darkstar.32430
Organization: University of Chicago CILS
Originator: osr@ftp

In article <32391@darkstar.ucsc.edu> rminnich@super.super.org (Ronald G Minnich) writes:
|Since this group seems to have revved up I thought I might 
|drop in some comments on assumptions that some of us in 
|the supercomputing community see in the research we 
|have studied. Note: I want to differentiate "supercomputing" from 
|"supercomputer". We do a lot of "supercomputing" here without 
|touching a Cray, some of it via our own architectures. 

|1) In a computer system, all significant computations performed on 
|   data in the main memory are performed by fetching the data to the 
|   CPU over the main memory bus, operating on it, 
|   and storing it back to memory. (by significant I am trying
|   to eliminate scsi interfaces, graphics hardware, etc. )
|
| [...more of the same...]
|
|5) "most" files are less than 4K. Stated differently, the mean file size
|   is around 40xx bytes, with a very small standard deviation. 
|
|   Maybe true in environments that don't do a lot of computing. 
|
| [...more of the same...]
|
|10) Optical networks have such a low bit error rate that we don't have
|    to worry about drops or misorders any more. 
|
|    I can't even figure out how low BER justifies the assumptions
|    re ordering and drops. But I have at least one paper that makes this
|    statement. 

You bet; though I have trouble seeing much of a difference between
"supercomputing" and any other kind of computing. We *all* want our
answers yesterday, and we're *all* always short of disk space....
Maybe the difference is that I think floating point is the creation of
the devil? :-)

A couple of years ago I did a preliminary study for a system that
would keep a randomly accessible digital copy of the film archives of
A Major Broadcasting Company, distributed across the continent, and
including swallowing realtime video feeds (not only of what was
actually broadcast, of course, but also of what wasn't, and including
all regional variation). When I called this the Small File System
*they* thought I was joking. But now I have friends at Fermilab, a
place that seems to survive on lossy compression....

There's no especial reason to assume that such data aren't going to
pass through some CPU somewhere, of course, but they probably aren't
all going to get streamed through the same one....

As a rule of thumb, file sizes can be considered to range from zero
bits to at least several terabits, and *any* static assumption about
distribution is going to burn you. In particular, both ends have to be
handled cleanly.

And archivists - and physicists - can get *pissed* if you drop a
bit....
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------
From: lance@unix386.Convergent.COM (Lance Norskog)
Newsgroups: comp.os.research
Subject: Re: futures (was Async comm. vs RPC)
Date: 14 Apr 92 01:09:56 GMT
Organization: Unisys/Convergent, San Jose, CA
Originator: osr@ftp


jpab+@andrew.cmu.edu (Josh N. Pritikin) writes:

>So what are futures?

Ideally:
	{
		future int rpc1(), rpc2(), rpc3();
		int a, b, c, d;

		a = rpc1();
		b = rpc2();
		c = rpc3();
		
		...
				<--- block once until all three rpc's finish
		d = a + b + c;
	}

There's a C++ toolkit from MCC that does this somehow.

I think you need compiler support to "block once" instead of "block thrice".

Lance Norskog
From: philw@alice.att.com (Phil Winterbottom)
Newsgroups: comp.os.research
Subject: Plan 9 process/thread comment?
Date: 8 Apr 92 03:31:45 GMT
Organization: AT&T, Bell Labs
Originator: osr@ftp


>From: fouts@hplmf.hpl.hp.com (Martin Fouts)
>Subject: Plan 9 process/thread comment?
>Date: 7 Apr 92 16:30:35 GMT
>
>I think I'm missing something about plan 9 from the limited reading
>I've done.   In particular, how do you deal with ...

We are very interested in multiple processes sharing address spaces. What we
are trying to do is make the overhead of doing the management so small that
we don't need to distinguish between processes in the operating system and
some kind of other thread mechanism. Various pieces of operating system
support make this viable:

	* User level process locks at memory reference cost

	* Flexible memory segment control between groups of processes

	* Low cost system call interface >14uS (~250 instructions)
	  on our SGI MP machines

	* A fork which allows selective sharing of various resources including
	  memory, file tables, locks, environment and notes.

	* Two synchronisation system calls to interface to the scheduler
		rendezvous - to provide a cheap synchronisation primitive between
			     processes in the same process group.
		sleep(0)   - to reschedule the processor

We have multithreaded servers which use these pieces of the OS. All the
processes are scheduled preemptively. If you want co-routines
(non-preemptive) then a user level co-routine package is what you
should use, this is how the window system file server works.  The Plan
9 C compilers are all caller saves so a context switch for a co-routine
need only save PC/SP and can be implemented in about 5 instructions on
the mips. This should not be confused with the need for threads in or
out of the kernel. A parallel application will typically be a balance
between cooperating processes executing co-routines to achieve the
performance you need, you still have to pick the right tool for the
job.

Phil Winterbottom
From: yodaiken@chelm.cs.umass.edu (victor yodaiken)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 10 Apr 92 01:32:55 GMT
Organization: University of Massachusetts, Amherst
Originator: osr@ftp


In article <32424@darkstar.ucsc.edu> welch@parc.xerox.com (Brent Welch) writes:
>I don't understand this statement about file servers making client
>caching difficult.  The Sprite and Andrew file systems are examples
>of systems in which the file servers take explicit action to support
>client caching.  Both systems work very well, wich client caching
>reducing network and server load.  Of course, it is possible to design
>a file server that makes it hard to do client caching correctly,

Sprite, at least, explicitly incorporates the file system into the
kernel.  If the Sprite file system can be considered to be an example of 
client/server , then any o.s. facility can be considered to be within the
client/server paradigm. There seem sufficient interactions between 
memory management, process control, and file systems to make high
performance depend on tight connections between these system. 

>client/server splits are natural reflections of modular boundaries in
>a distributed system.  Granted, at some level you can hide the client
>server split, but under the covers the split is important.

Perhaps we mean different things by "client server paradigm". Certainly
I'm not about to argue that distributed systems are not distributed. But,
structuring o.s.'s in terms of "server" processes which encapsulate such
systems as the file system or the network name space is a popular
strategy which does not seem to me to have been validated by practice,
NFS  aside. 


-- 


yodaiken@chelm.cs.umass.edu



Newsgroups: comp.os.research
From: bellcore!gizmo.bellcore.com!mo@uunet.UU.NET (Michael O'Dell)
Newsgroups: comp.os.research
Subject: Re: A challenge (response)
Date: 10 Apr 92 12:02:05 GMT
Organization: Center for Chaotic Repeatabilty
Originator: osr@ftp

Harumph!!

I already said I don't think we have learned much.

And as for your comment of "worrying about factors of two",
I qoute Stu Feldman:

	I never worry about a factor of two
	The problem is, neither do nine of my friends.

This mentality is EXACTLY why systems are big and bloated and slow.
I'm not advocating coding in assembler, but I AM saying that it is
wrong to assume overall system performance is someone else's problem,
and assuming a factor of two is disposable is simply indefensible.

SO I'll go even further at the risk of drawing fire -
I think many distributed systems people have learned WRONG things.

	-Mike O'Dell
	Resident Crank headed for the bomb shelter

Bellcore??? Hah! Bellcore isn't allowed to have opinions. These are mine.