Concurrency, was Re: Doh! Stupid Programming Mistakes <humor>

Levi Pearson levi at cold.org
Thu Oct 26 11:31:47 MDT 2006


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



More information about the PLUG mailing list