From: gdtltr@ravel.udel.edu (Gary D. Duzan)
Newsgroups: comp.os.research
Subject: Re: futures (was Async comm. vs RPC)
Date: 11 Apr 92 21:03:59 GMT
Organization: Your Organization Could Be Here!
Originator: osr@ftp


In article <32551@darkstar.ucsc.edu> jpab+@andrew.cmu.edu (Josh N. Pritikin) writes:
=>> Futures allow RPC to be used intuitively *and* the RPC to succeed
=>> immediately w/o violating the semantics of the program. Futures are very
=>> efficient w/ tag memory support. However, futures can also be transparently
=>> supported through classes (C++ or otherwise) on systems w/o hardware
=>> support.
=>
=>So what are futures?
=>
   A future is an object that will have its state assigned sometime in the
future. Attempting to access the state of a future will cause the thread/
object to block until the state is assigned by another active entity. For
example, if a function call is defined to return a future, the program
calling the function, upon making the call, will immediately be returned
a future, which it may assign to a variable, move around, and so on. The
function would then be scheduled as another thread, run on another
processor, or whatever, depending on the implementation. If the return
value of the function is never read, the program completely avoids the need
to block on the function call. Futures are being used in Ellie, a language
for the support of variable-grained parallel objects being developed (last
I heard) at DIKU, Denmark.

Obligatory OS Statement: I am currently stuck in an MS-DOS shop, and I'll
take anything better right about now. :-) Seriously, though, I think there
is a lot of potential in an intelligent use of lightweight processes
(probably mixed user/kernel, like Scheduler Activations), RPC, and futures.
I also think it might be useful to look into Coordination Languages
(CACM, 2/92) before Gelernter and Carriero convince everyone that they can
do away with operating systems with them. (Not that it wouldn't be nice to
have a unified communication abstraction. Sorry, John. :-) I think I'll
have to go with the microkernel camp on the kernel architecture issue. I
tend to agree with the points already made about reliability, portability,
and modularity. On group communications, while useful, I think a low
priority for moving into the kernel. Client/Server is a good paradigm. So
is Peer/Peer. Distributed Shared Memory has never appealed to me,
particularly: I prefer explicit communication primitives to strange memory
tricks (at least at the application programming level). Anything that we
can do to make a distributed system more reliable and still worth
distributing is a plus in my book. I see no point in designing a system
to be fast if it isn't going to be reliable. That's enough rambling for
now; maybe I'll ramble some more later.

                                        Gary Duzan
                           Mini/Micro Computer Network Specialist
                                  Delaware State Hospital



-- 
                              duzan@cis.udel.edu
   _o_                        ------------------                          _o_
 [|o o|]        Virtual Reality? No thanks, I've already got one.       [|o o|]
  |_o_|        Disclaimer: I have no idea what I am talking about.       |_o_|


Newsgroups: comp.os.research