Hi Gregg,
On Oct 1, 2007, at 9:37 AM, Gregg Wonderly wrote:
Bill Venners wrote:
Anyway, I was curious what everyone here thought. It may be a way
to position River in people's minds, give it a marketing story.
I think this is a reasonable analogy to use. Some will still argue
about the locking that occurs in the JavaSpaces server etc. But, I
think there is some meat to the argument that the design of
parallel systems should be thought of as a distributed computing
problem.
I'm not sure what you mean about "the locking that occurs in the
JavaSpaces server," but if you mean that JavaSpaces is implemented
using shared state and locks, that's OK. When you send a message to
an actor there's locking and shared state going on in the actor's
message queue. What's important is that clients of the actors don't
need to explicitly lock anything. Client programmers can think at a
higher level of abstraction, and the model is composable. I think
such things would be true of a JavaSpaces compute grid model.
One complaint I can imagine is that you'd be using processes instead
of threads, except that you could have a single worker process with
many worker threads each operating independently. Even a master
thread could be doing the work of the master in the same process,
also independently. What people might find a bit odd is that
JavaSpaces itself is in a different process, and you have to go over
TCP/IP to pass jobs and results back and forth between master and
worker threads, even when those threads are in the same process.
But I think the answer to that could be that this is how you make it
possible to just add another box and scale horizontally when you need
more workers. One thing that is apparently true about actors, and
again sorry I don't understand this model very well as yet, is that
if your program works on one box it will work on many. That's a
pretty useful feat. In the case of JavaSpaces, what it would mean is
that you treat all objects the same whether they are remote or local,
because you treat them all as if they are remote. So you handle
partial failure of a different core on the same CPU, which is pretty
unlikely to ever happen. But it is worth hit, because when you do
that you can indeed just add more boxes with more cores and your app
scales.
Anyway, I was just speaking last week to a high-level director of
software at a large enterprise. I mentioned Jini and asked if he'd
heard of it. He said, "Oh yes, that's about writing software on
devices, right?" Jini has a new name now, River, so perhaps there's
an opportunity for a new marketing story. I have noticed that there
has been a lot of concern in the software community recently about
the coming proliferation of multi-core architectures. It smells like
a disruptive technology is coming, and that may be an opportunity to
explain River in a way that makes people feel it could help them
solve a real problem that they expect to be facing very soon.
Bill
