Hans,
> There are several possible idioms that might be used to enforce that
> the correct thing happens:
>
> 1) Make all methods which might be the last ordinary call on an
> object synchronized. Make the finalizer synchronized.
>
> 2) Write to a volatile field at the end of ordinary methods,
> and read it first thing in the finalizer.
>
> 3) Put "synchronized(this){}" at the end of ordinary methods and at
> the beginning of finalizers.
>
> ...
> I think I'm inclined to go with (3) in my main example.
I'm a little confused - but given the context that is hardly surprising. You
seem to be implying that the cure for this problem lies in the code of the
class of the object we don't want prematurely finalized. My understanding of
the problem was that it is only possible if the object is currently only
referenced through a stack variable, rather than a heap variable. Hence it
is the method of the class that *uses* the object that must take special
steps to prevent premature finalization. So if the finalize() method is
synchronized, or employ's synchronization, then the method using the object
should have a "synchronized(theObj) {}" block to prevent the finalization
from occurring prematurely.
The idea that any class with a finalizer should add a sync block to the end
of all methods is just too horrible to contemplate. I'd probably prefer a
write to a private volatile as a cleaner mechanism if this is the way to do
this.
BTW this is one talk I'll definitely be attending. :)
Cheers,
David Holmes
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:09 EDT