I have been re-reading the discussion on finalizers. The general trend of
the discussion is that all finailzers should be synchronized since they can
be run on a separate thread. I don't believe that for most usages and most
(if not all VMs) that rule is actually correct. The process of identifying
objects to be finalized actually has the effect of ensuring that the GC
thread (whichever that is) is guaranteed to have seen the last write to the
object at the point that it realises that there are no remaining strong
references to the object. So, does the GC thread pass on that guarantee to
the finalizer thread ? I believe that in current VMs it does since the
process involves a monitor controlling a list of to-be-finalized objects.
If the VM chose to employ some atomic operation not involving memory
barriers then of course the guarantee would not be passed on. However, in
general a single monitor operation will perform much better than many
atomic operations and thus I believe that current VM's would have no
problem in making the guarantee that a finalizer will behave as if there
existed a 'finalization lock' on the object. This lock is released after
the last update of the object and obtained by the finalize method. For a
large class of users this guarantee would be all they needed to avoid them
worrying about synchronization simply as a consequence of the VMs decision
to employ a separate finalizer thread.
Martin Trotter
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:44 EDT