> -----Original Message-----
> From: Igor Pechtchanski [mailto:igor@watson.ibm.com]
> Sent: Tuesday, April 01, 2003 3:43 PM
> To: Paul Jakubik
> Cc: javamemorymodel@cs.umd.edu
> Subject: RE: JavaMemoryModel: Another Java threading issue
> (finalization)
>
>
> On Tue, 1 Apr 2003, Paul Jakubik wrote:
>
> > My understanding of what has been proposed in this thread is
> > that the developer should do the following:
> >
> > If your class has a finalizer you must synchronize any
> > potential last-method-call and the finalizer.
> >
> > If I understand this correctly, this sounds like bad news for
> > library developers. It would mean that every method and the
> > finalizer should be synchronized (at least every public
> > method). The library would be made significantly slower in
> > hopes of allowing an optimization to make the library a little
> > faster.
I think we mostly agree that this is already necessary. Most of us believe that the current spec is not enough to guarantee that it is sufficient. I'm proposing to at least make it sufficient.
We're not proposing to slow down existing code. We're giving it the opportunity to be correct. (Correct code may of course be slower than incorrect code ...)
It's important to remember that this is only necessary for classes with nontrivial finalizers, of which there hopefully aren't many.
It's certainly possible to think about alternatives that avoid the locking. But those seem to involve significant changes, at least to JVM implementations. My inclination would be to first fix the spec to allow guaranteed safe use of finalizers. If that uncovers real performance issues, those can be addressed later.
> >
> > Am I missing something? If my interpretation is right, are
> > there alternatives that would make the developer's life easier?
> > --Paul
>
[ Igor Pechtchanski: ]
> I'm sorry to be jumping in here, but as far as I understand,
> if you want
> your library to be thread-safe, you'll need to synchronize
> all public (and
> protected) methods in it anyway, so you're not really losing any
> performance. Besides, (a) it's safer to eliminate unnecessary
> synchronization in the compiler, and (b) locks are cheap anyway unless
> there's contention...
That depends on your notion of thread-safety. I agree that you may need the synchronization anyway, but not always. The need for synchronization is not unexpected, since finalizers do run in a separate thread.
Locks unfortunately aren't always cheap. The underlying compare-and-exchange operation or the like typically takes between a few dozen and a few hundered cycles, in the absence of cache misses. The details depend heavily on the platform.
Eliminating the "unnecessary" synchronization here sounds tricky (the object is being accessed by more than one thread), but I haven't thought about it enough.
My only argument that the performance cost is tolerable is that finalization is usually rare.
Hans
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:43 EDT