river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Venners <bv-...@artima.com>
Subject Re: Concurrency and River
Date Mon, 01 Oct 2007 17:13:28 GMT
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  

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.


View raw message