Bill Pugh wrote:
>> Personally, I like the idea of a GC.KeepAlive method, as in the .NET
>> Framework.
>
> We talked about this before. We never reached a consensus at a level
> required to force an API change,
> and now it is too late to add a new method to the API.
>
> We do guarantee that you can achieve this by either synchronizing on the
> object after
> updating it, and synchronizing on it again in the finalizer, or
> alternatively
> writing to a volatile field of the object after updating it, and reading
> that
> field in the finalizer.
I assume that, by "after updating it", you mean "after accessing the
global data structure".
So, GC.KeepAlive is what we would really want to do, both in terms of
syntax and in terms of semantics, but for compatibility reasons, we tack
the semantics of GC.KeepAlive onto an existing construct, i.e.
synchronization. I can live with that.
If I understand correctly, the reason why this is better for
compatibility than introducing a new API is that existing code that
performs synchronization automatically becomes correct and that existing
code that does not perform synchronization is unlikely to be correct
anyway. Okay, I can see that to some extent.
On the other hand, if we had GC.KeepAlive, it would be perfectly valid
to have an I/O class that requires callers to synchronize access to the
library (think AWT or Swing) and that uses GC.KeepAlive, and then the
I/O class would be correct in the absence of synchronization.
But I can see how the proposed approach is a good compromise between
compatibility and optimal design.
Bart
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:05 EDT