Brian McCallister has started a great set of posts on futures. This fits in perfectly with my work with Gregor Hohpe on Mercury, a light-weight messaging library for Java. Brian explains futures:
Futures are really nice conceptually, and provide for much more natural and easy to use concurrent design than Java style threading and monitors. It relates to a lot of functional programming concepts, but the key idea is that a future represents an evaluation which has not yet occured. Maybe it is being lazily evaluated, maybe it is being evaluated concurrently in another thread.
Java has no futures, but I do fake closures using reflection and a sort of distended proxy. The core of Mercury is that when code publishes a message to a channel, it is not immediately delivered. Instead, the channel records an activation record (binding) and begins reordering the records before activating the bindings. This lets Mercury have breadth-first message delivery instead of depth-first, and circumvents the effects of using a call stack in a messaging system.
Gregor's excellent Enemy of the State post describes the thinking in more detail along with some ramifications. I'm just the humble mechanic who coded the library. :-)
UPDATE: I just got an anonymous comment pointing me to java.util.concurrent.Future. Zowie! That's a cool thing to find.
4 comments:
actually java does have Futures - as part of the superb java.util.concurrent library that is part of JDK 5 - http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Future.html
Very cool -- thanks for pointing me to that!
Oops. Fixed the link.
If you're interested in Futures then you should read James Noble's paper: http://citeseer.ist.psu.edu/107777.html where he categorises the various different kinds of Argument/Result objects and their concurrency traits.
Post a Comment