Pete.Soper at Sun.COM
Fri May 19 14:46:24 EDT 2006
Jeremy Manson wrote:
> If you are looking at a single thread in isolation, program order means
> the order in which the statements in the source code occur, and the
> order in which the bytecodes occur.
But if I'm sitting in gdb it doesn't look quite the same, and my
interpretation of Robert's "Visible VM" view would show an astonishing
sequence of memory references, making mapping back to source order and
complete understanding quite a job for even a short program. But I'm
getting the message that delving into "program order" is just not
profitable and I think it's interesting that Java Concurrency in
Practice gives extremely brief mention of compiler/hardware
optimizations. Until I find out otherwise I'm going to conclude this
detail is distraction from the more important points.
>> But back to your statement. I don't agree. The memory model *does*
>> have relevance to single threaded programs, as the "constructor
>> completion happens-before finalizer runs" rule shows us. At least I
>> hope it does! It would be terrible if the finalizer thread can say
>> "well, we're tired of waiting: lets just run this thing anyway." Put
>> a different way, even if the developer thinks they have a 100%
>> single-threaded application, it's not running in a single-threaded
> I think that, rather than saying that the memory model has relevance to
> single-threaded programs, I might instead say that there are no
> single-threaded programs in Java. Finalizers are a good example of why
I was attempting to say this.
> this is true - an object's finalizer will never run in the same thread
> in which the object was constructed, and there is nothing in the spec
> that suggests that it might. This is one of the reasons why having some
> understanding of multithreaded programming and the memory model is so
I think this is a key point. Java programmers cannot avoid understanding
the JMM to some degree. The big question in my mind is what the
essential subset is to communicate?
> Kazimierz's original code should do what it was intended to do because,
> once again, of the precision of exceptions. Again, the write to the
> committed variable, for example, will only occur if the exception is not
And you also wrote:
> Hopefully, you shouldn't be too tempted to write finalizer methods.
A friend's description of a talk by Hans Boehm at JavaOne last year made
me simply stop thinking about finalizers. It's part of the pain of this
job to have to deal with the fact that they haven't been yanked out like
a bad tooth (insert corporate disclaimers here). And you're right, edges
would have to be laid down in places to allow precise communication
between object and finalizer, with the one from "last object use" to the
finalizer being the essential subset.
This has been a very pleasant exercise. Thanks again.
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest