Bill,
I discovered this too, and thought that the spec was completely hosed. On
further investigation, I found that elsewhere in the spec, it says that the
thread that runs finalizers "holds no user-visible locks" or some such. I do
not remember where it says that, but I'm sure that someone else on the list
remembers.
Josh
P.S. It really is unfortunate that it doesn't say this in the obvious place.
Hopefully Gilad has fixed this in the next Ed.?
-----Original Message-----
From: Bill Pugh <pugh@cs.umd.edu>
To: javaMemoryModel@cs.umd.edu <javaMemoryModel@cs.umd.edu>; Gilad Bracha
<gilad.bracha@eng.sun.com>
Date: Sunday, March 26, 2000 7:32 AM
Subject: JavaMemoryModel: Finalizers must be run in a finalizer thread
>As we've discussed, proper design of non-trival finalizers requires
>synchronization.
>
>However, the draft of the 2nd edition of the JLS says (Section 12.6, page
259):
>
> "Also, the language does not specify which thread will invoke the
finalizer."
>
>That has to be changed. Otherwise, you can't guarantee that
>synchronization in the finalizer actually enforces mutual exclusion.
>
>For example, say a system statically determined the point on which
>some thread local objects became garbage, and invoked the finalizers
>inline (to allow the objects to be stack allocated). Then since the
>finalizers are being run in the same thread as likely holds any locks
>on the objects the finalizer is locking, the locks have no effect.
>
>I think it would be OK to just change the spec to say:
>
> "Finalizers are run in a thread that doesn't hold any locks at the
>time the finalizers are invoked".
>
>I think this is separate enough from the memory model issues that we
>should fold it into the current JLS revision, rather than waiting for
>the JMM JSR.
>
>Comments?
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:25 EDT