[concurrency-interest] New bug pattern, way to common
jdmarshall at gmail.com
Sun Mar 23 14:57:24 EDT 2008
I can only recall using synchronize(getClass()) willfully in one
scenario (a couple occasions), and that was when I was building tables
of metadata about classes.
I don' tend to use class metadata in that manner anymore, so I haven't
used it in quite some time. But I bet plenty of frameworks still do.
Especially class manipulation kits, but I suspect Hibernate does as
On Sun, Mar 23, 2008 at 11:19 AM, Gregg Wonderly <gregg at cytetech.com> wrote:
> Luke Blanshard wrote:
> > This is still buggy. Suppose you added class C extends A, and have
> > thread 1 create an A and thread 2 create a C. Now the inc method will
> > be able to run simultaneously in both threads.
> > It would only make sense to synchronize on getClass if there were "class
> > instance" variables in Java, as in some variants of Smalltalk.
> I don't know that I have a great example of when this behavior would actually be
> correct. It seems like findbugs could alert one to refererences to non-final
> or non-private references within synchronized(getClass()) blocks. I.e.
> getClass() is okay as long as it's referencing things that only this "Class"
> instance can see. As in this example, that would include instance variables as
> well as methods. If increment() were final or private, then it's reference
> would be okay. It might also be okay to reference methods that were abstract.
> So, I'm not sure that this could be called a problem coding practice as much as
> an advanced coding construct that needs careful attention to use correctly.
> Gregg Wonderly
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest