[concurrency-interest] reordering

Pete Soper Pete.Soper at Sun.COM
Fri May 19 14:46:24 EDT 2006

Jeremy Manson wrote:
> Hi,
> 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
>> environment.
> 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 
> important.

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

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.


>                     Jeremy
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list