On Oct 26, 2006, at 10:23 AM, Bryan Sant wrote:
I don't believe that Java's threading model is the best that could be,
but I do find it more than worthy to utilize in the face of existing
alternatives today. Given Java's model (an others who have similar
capabilities), I don't find any virtues in the child-process model of
concurrent programming compared to threads. But I do appreciate this
discussion, I find your opinions to be very sound and well thought
out. You are a true thinker and I appreciate your insights and
opinions. I hope I haven't been too offensive with my pseudo insults
above.
With your latest response, I think we are actually far closer to
being in agreement than I thought earlier. I do think you may have
misunderstood my initial post, though. I was responding to someone
who was talking about experience in a computer architecture class
that was dealing with Unix/Linux, C, and processes/threads in that
context. In that specific case (especially with Linux's COW heap for
fork()) it's worth considering using child processes first before
threads because of the immense complexity increase of shared-state
concurrency.
When programming in Java, you aren't really programming in the Unix
environment, you're programming in the Java environment, and the
tradeoffs are different. It's FAR safer and easier to do threads in
Java than in C/Unix, plus there's FAR more overhead in creating a
child process. This is a significant change in the equation! I
would certainly not advocate creating child processes in Java or high
level languages in general, but I would advocate using concurrency
tools that provide just the right level of abstraction necessary for
your problem.
In high-level languages, although there is always shared-state
concurrency at the implementation level when threads are used, the
abstraction of the language can provide safety with other models of
concurrency without resorting to using the OS for protection. With
Java's lack of raw pointers, you do get to partition the heap space
that can actually be accessed by different threads, which is
certainly a step in the right direction. Limiting the shared state
in shared-state concurrency is the only way to effectively manage it.
However, high-level languages can also offer other concurrency models
on top of threads, such as deterministic dataflow concurrency (such
as with 'futures') and message-passing concurrency (such as in
Erlang, for example). And in the case of shared-state concurrency,
composable concurrent abstractions can be provided by eschewing locks
altogether and using transactional memory instead (Scheme48 does
this, for example, as does Pugs now). All these things could
conceivably be offered by Java, though to my knowledge they are not
right now; the massive class library is built around the assumption
of shared-state threads with locking for protection against race
conditions, so it would take a massive effort to re-tool it. I can
see locks being replaced with transactional memory, though, since
most Java concurrency primitives are above the level of raw locks.
Anyway, it's been an interesting discussion, and hopefully it has
convinced some C/C++/Unix programmers to think a bit more about
concurrency. With the rise of multi-core processors, it is going to
become very important in the near future.
--Levi
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
