river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: Concurrency and River
Date Wed, 03 Oct 2007 05:43:00 GMT
Hi Bill,

In advance sorry for the lengthy response, but your postings cover a lot
of areas.

Bill Venners wrote:

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

I agree with your notion above, although I really wonder to what extent
models employed by Erlang or other functional languages and
'asynchronous message libraries' move the difficulties involved with
parallel/distributed programming to another place, a place that might be
equally hard to reason about by the average programmer.

My involvement with functional languages (besides XSLT) has not extended
beyond the trivial cases which might give you a feeling of victory. As 
Dan mentioned I think there are a lot of people pursuing a silver bullet 
here and while getting older, I found that most shiny things turn into 
rusty old pieces the longer you work with them.

While reading the Erlang book I was constantly thinking where do I leave
my state that must be accessible by other processes and how can I query
it. Probably not strange when you learned programming as an 11 years old
with BBC Basic (this will earns me some credits by the English people I
guess) with integrated assembler for the MOS 6502, then C and then Java
so I have to realign a lot of brain cells. Although it might be that a
nice mixture of functional and imperative programming (such as Scala) is
the way to go.

I think it would be interesting to see somebody implement the equivalent
of e.g. ServiceDiscoveryManager in Erlang or Scala and see whether that
would be really easier to implement and reason about. If that is the
case it would argue in favor share-nothing message passing.

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

Sometimes I wonder whether the exposure of Erlang is only due to
multi-core. SMP machines are out for a long time already as are
multi-core CPUs. I can't withdraw myself from the impression that in
general a lot of languages are getting a lot of attention because Java
has become the new COBOL and there is so much API/technologies, etc. in
the Java world that people are longing for newer grounds where they can
explore and comprehend the complete landscape and make a difference.
More than 10 year of Java experience and I seem to know less than after
the first year of Java which frustrates me at times. And it is clear
that Java is probably too static for a lot of purposes given all the
bytecode manipulation and reflection going on these days which often can
be handled by some dynamic language much more elegant. And at the same
time Java is doing rather bad (in market acceptance) in the areas it was
designed for and for which the strong security model and mobile code
really made sense and which seems to be what really sets it apart from
other languages/platforms.

Note also that distributed Erlang (messaging) is based on a trusted
environment while the original Jini goals were an untrusted environment.
I have no idea yet of the exact code mobility characteristics of Erlang
but it will be interesting to see how they will be dealing with that.
Also Scala is lacking a strong security model which, if you take code
mobility into account, seems to be a necessity.

> I'm not sure how NUMA would affect things, but local versus remote 
> 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.

I think that by definition most client-server applications are already
designed with parallelism in mind, although maybe many of them put the
actual handling of that towards the database and work through
database transactions. These systems must have been exposed to SMP
systems because after all the Sun E10000 with 64 CPUs is already more
than 10 years old and in that time I even worked with an E450 that had 4
CPUs and I've seen a lot of 8 CPU boxes in banks. So for many of us this
is not really new and I think for those working with Jini parallelism is
like a second nature, which doesn't mean it is easy, the contrary.

What we see though is that a lot of single threaded applications that
were able to get 100% CPU utilizations are not able to take advantage of
all those cores and for them it will require a shift in thinking.
Although for many applications I think it is enough to think of a
problem as a local parallelization problem versus a distributed
parallelization problem and doubt whether JavaSpaces is the best way to
go. So I'm hesitating to submit a Wide Finder implementation
based on a (local) JavaSpace to Tim Bray ;-)

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

I guess so, JavaSpaces still represent the JavaSpace specification. As
the incubator reports mention "River is aimed at the development and
advancement of the Jini technology core infrastructure" I also think
Jini is still alive and kicking although still not a noun, so I think it
is not correct to state that Jini isn't called Jini anymore.
-- 
Mark









Mime
View raw message