> But I do want to caution the EG against adopting a position
> that may be
> perceived as out of touch with reality. And I want to
> encourage the EG to
> continue in their efforts to make the entire JMM specification
> understandable to everyone.
>
I agree with this goal. But I'm less optimistic about current reality.
As far as I can tell, we have a long tradition of doing almost anything related
to concurrency in a way that's less than 100% correct. Even if you
go back to ancient Unix source code, way before threads, there was a tradition
of doing things like longjmping out of asynchronous signal handlers. This was
bound to fail every once in a while, but nobody noticed much, because the failure
probability was small. (I pick on this code, since I think all of us would
agree that it was among the best written and certainly most successful of the time.)
The best of modern multithreaded code (or code with finalizers, or any other
form of concurrency) preserves this trend, though much of
it seems to exhibit higher failure probabilities. Most of the time, when I read
a substantial piece of multithreaded code (including what I wrote earlier),
I find substantial bugs by inspection.
I agree that we should minimize harm to the existing code base. And I would be
surprised if the current proposal does. But I also think there is a large upside
potential here for code reliability. Our previous story about what it means
to write correct multi-threaded code just wasn't very sound at the lowest levels.
That makes it hard to teach anything very coherent about multithreaded programming,
or for library implementors to even know what they should specify, or for people
to build the right tools.
Hans
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:53 EDT