David -
My model was that in the ResourceManager code, both useA and useB
end with something that enforces reachability of "this", i.e. the
ResourceManager.
The sync block is used only to enforce reachability of "this". It
is not used for mutual exclusion in this model. That has the advantage
that the sync blocks can be empty, and thus the locks don't need
to be held very long.
Similarly, a store to a volatile field relies on the statement in
the memory model that that will keep the object from being finalized.
I think you make an important point in that this breaks if the
finalizable field gives the client direct access to a subobject,
which is cleaned up by the finalizer. I think the story there is
1) Don't do that.
2) Don't do that.
3) In case you really need to do that, you need a keepAlive mechanism
that is usable by the client in such cases. Empty synch blocks
and Jeremy's keepAlive would work.
Am I missing something?
Hans
On Sun, 1 May 2005, David Holmes wrote:
> Hans,
>
> > I believe it works either way. You can also use a
> > synchronized(this){} at the end
> > of every ordinary method call which might be the last call on the
> > object. And it hides this mess inside the object with
> > the finalizer.
>
> I don't see how this is the case. If the object's own methods perform the
> sync block then that only ensures that the object remains reachable during
> execution of that method. If the client uses the object via a local then the
> client must ensure there is no premature finalization.
>
> eg.
> void someMethod() {
> ResourceManager man = new ResourceManager();
> int result1 = man.useA();
> int result2 = man.useB();
> }
>
> If the ResourceManager finalizer clears resources A and B then the caller of
> someMethod needs to prevent premature finalization of the ResourceManager
> instance. If useA and useB include a sync block at the end that only ensures
> that the finalizer will run either before useA, between useA and useB, or
> after useB.
>
> My understanding of this issue is that the client code - that which is
> referencing the object - must do something to ensure the object remains
> reachable, but following some protocol involving the finalize method of the
> object concerned.
>
> Cheers,
> David Holmes
>
> -------------------------------
> JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
>
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:10 EDT