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 Tue, 02 Oct 2007 02:17:00 GMT
Hi Dan,

On Oct 1, 2007, at 12:26 PM, Dan Creswell wrote:

>> Brian Goetz has brought up that we may have frog-boiled ourselves  
>> into
>> an bad situation by adopting the model of shared state with locks in
>> Java. In general the shared state/locks model makes concurrent  
>> programs
>> difficult to reason about, but in particular this approach to
>> concurrency isn't composable. You can't safely combine different  
>> modules
>> without understanding the details of what they do with locks and how
>> they will interact.
>>
>
> That's just about the consequences of shared state with concurrent
> access be it using locks or transactional memory etc.
>
> And I think in general concurrency is difficult to reason about  
> even in
> message based systems with shared nothing because you still have  
> issues
> of failure to deal with including how that might impact message  
> delivery.
>
Concurrency may be difficult to reason about in general, but some  
models are more difficult than others. Some models make it impossible  
to trip in certain ways, just as it is impossible in Java bytecodes  
to free a pointer to memory twice. As I understand it, Erlang  
prevents deadlock by only allowing threads to interact via messages.  
Transactional memory can still produce starved threads that keep  
retrying and keep getting rolled back, but the app as a whole will  
make progress because some threads will be getting stuff done. Java's  
basic model of synchronization is a bit more like a mine field,  
because you have to understand the whole application, including  
everything libraries are doing with locks and callbacks and such, to  
be sure there are no potential deadlocks. And that's really hard to  
do by analysis, and it is hard to detect problems via testing because  
they can happen quite rarely.

If you have a JavaSpaces client that looks at how many CPUs or cores  
it has to work with when it starts up, and fires up one master thread  
and enough worker threads to keep all those cores busy, assuming each  
thread is an independent guy that only communicates with other  
threads over the network via a JavaSpace, then those threads can't  
deadlock. (Though I supposed you could design a JavaSpace protocol  
that could hang them up.)

>> The Pragmatic Programmers recently published a book on Erlang,  
>> which got
>> a lot of people taking about Erlang. Erlang uses a shared nothing  
>> model,
>> with message passing between "processes" managed by "actors".  
>> Processes
>> can be implemented as threads I assume, or can be distributed. One
>> interesting thing about Erlang is that it tries to unify the  
>> remote and
>> local models, as far as I can tell. Not that they haven't read a  
>> Note on
>> Distributed Computing. I think that instead of trying to make remote
>> nodes look like local ones, they may treat local ones as  
>> unreliable as
>> remote ones.
>>
>
> I've yet to see exactly how Erlang does failure detection of  
> processes.
>  I guess there might be some timeout value somewhere in respect of
> messages reaching a destination etc but I've not seen a description of
> this aspect of Erlang.
>
> Further whilst Erlang might do failure detection (of a form)  
> solving the
> issues of failure are the difficult bit and I'm less convinced Erlang
> offers much here.  For example, one solution to failure is replication
> and it appears you are (unsurprisingly) left to do that for yourself
> right now.  Putting my high-performance hat on I'd also point out that
> replication has recognized limits especially when it's done with
> transactions which leads to even more esoteric solutions that are
> largely about appropriate architecture/interactions and less about
> shared-nothing or message passing.
>
I'm not trying to promote Erlang's approach, only to point out that  
it is getting a lot of buzz, because people are thinking about multi- 
core.

>> I've been involved with a language called Scala lately, which has an
>> Erlang-like actors library. On the mailing list they keep talking  
>> about
>> issues with implementing remote actors. I as yet don't understand  
>> these
>> details either, but I keep getting this wierd feeling that wheel
>> reinvention is going on. They seem to be talking about how to solve
>> problems that Jini addressed almost 10 years ago.
>>
>> So here's my question. I get the feeling that the trend to multi-core
>> architectures represents a disruptive technology shift that will  
>> shake
>> up the software industry to some extent. Does River have something to
>> offer here? If you expect the chips your software will run on will  
>> have
>> multiple cores, and maybe you don't know how many until your program
>> starts running, you'll want to organize your software so it  
>> distributes
>> processing across those cores dynamically. Isn't JavaSpaces a good  
>> way
>> to do that?
>>
>> I think what it might mean is that you treat another core on the same
>> box running a worker thread the same as a worker thread across the
>> network. That way you have a uniform programming model, and when  
>> you run
>> out of cores, you just add more boxes and you get more worker  
>> nodes. So
>> it would be the opposite of the concept targeted by the Note. Yes,  
>> you
>> would use objects through a uniform interface, and whether or not  
>> that
>> object is implemented locally or remotely would be an implementation
>> detail of the object. But what you'd assume is not that the thing is
>> local (a thread on another core of the same box) but remote.
>>
>
> Hmmmm, so the uniform model concept is nice and cleans out one
> difficulty but there are some others lying around in this which I  
> reckon
> are in need of consideration:
>
> (1)  A number of multi-core systems are threatening to head towards  
> NUMA
> type architectures where the cost of comms is in part related to the
> number of memory spaces you have to hop.
>
> (2)  There's at least some (significant?) difference between comms
> performance across processors in the same box versus across a network
> and therefore the protocols you design and what you pass around in
> messages might be somewhat different.

I'm not sure how NUMA would affect things, but local versus remote  
interfaces usually get into considering chatty versus chunky designs.  
So my feeling was that if you really are going to just only ever want  
to exploit multiple cores on one box, JavaSpaces would be overkill  
because you can reasonably rule out partial failure. In the case when  
someone wants to exploit multiple cores, but also either distribute  
processing across the network as well, or at least leave the door  
open, make it easy to distribute across the network in the future,  
that JavaSpaces has a compelling solution.

I can imagine J2EE people all over the place in a few years  
scratching their heads about how they will take advantage of multiple  
cores for tasks they need done. Will they run a separate J2EE app  
server on each core? Seems like they could run one app server with  
multiple threads on each box. But then how do you distribute tasks to  
those threads? JMS doesn't have a take semantic. I suppose they could  
install a load balancer in front of a cluster, and have a master  
server firing jobs into the load balancer.

JavaSpaces solves this problem very elegantly, and has for a long  
time. The change in the status quo is that the rise of multi-core  
means more people will be trying to figure out how to do this kind of  
parallel processing than before. To exploit multi-core, you have to  
figure out how to partition your app so that you can do parallel  
processing. You have to find the parallelism. If you actually can do  
that, you next have to figure out how to implement it. The  
opportunity I see for River is a marketing one, to simply try and  
promote the idea that JavaSpaces can be used to solve this kind of  
problem. So when people face the problem someday, they'll think of  
JavaSpaces.

Is it still called JavaSpaces? Jini isn't called Jini anymore. What  
about JavaSpaces?

Thanks.

Bill




Mime
View raw message