Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <470149EA.90604@dcrdev.demon.co.uk>
Date: Mon, 01 Oct 2007 20:26:34 +0100
From: Dan Creswell <dan@dcrdev.demon.co.uk>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Concurrency and River
References: <E9192052-6EC2-4C9E-A8AA-29F0E5668262@artima.com>
In-Reply-To: <E9192052-6EC2-4C9E-A8AA-29F0E5668262@artima.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi Bill,

I think your idea is an interesting one and certainly and I think the
lessons learnt from Jini would be valuable in this area though I'm not
sure that Jini in its current incarnation is the correct base to start
from.  That of course might provide us with a target to evolve
towards.....or perhaps we start a side-project for this work, who knows?

Bill Venners wrote:
> Hi All,
> 
> I've been observing some wailing and gnashing of teeth lately in various
> programming communities around what to do about the rise of multi-core
> processors.
> 
> For example, the Python folks recently had some heated debate on Artima,
> for example, about something called the Global Interpreter Lock or GIL
> that in some way limits the concurrency potential of CPython. I don't
> quite understand the details, but there sure seemed to be some fear that
> if Python didn't make multi-threading easier, it may become less relevant.
> 
> 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.

> 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'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.

> 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.
> 

Very best,

Dan.