Comments on: Java Concurrency Bugs #5: inconsistent synchronization

By: Alex

Alex — Thu, 25 Mar 2010 16:39:09 +0000

@Matias: I think I understand what you’re describing. As to whether it is the equals() method or the other methods that are correct, that’s really hard for me to say without a lot more context about usage of these objects. If the other generated methods can be accessed from multiple threads, then I would say they are broken without synchronization and FindBugs is correctly detecting a bug. Sounds like the fix in this case might be in AndroMDA.

Alternately, it could be that AndroMDA is proactively (and incorrectly) generating equals() methods as synchronized. If these objects are used purely in a thread-confined way, then that synchronization seems unnecessary and again the fix seems like it should be in AndroMDA to not generate the synchronized on equals().

By: Matias

Matias — Thu, 25 Mar 2010 16:22:02 +0000

Hi Alex,

I have read your article on Inconsistent synchronization. Using the FindBugs tool version 1.39, published 5000 cases under this heading. The majority of them located within the implementation of the VO’s. Analyzing the code generated in these implementations is noted that like implements the methods of the class also implements the equals method. The strange thing is that the class definition and the method in question is generated by AndroMDA, that is self-generating the code under discussion. The peculiarity here is that the equals method is synchronized. Therefore FindBugs detected in the methods of the class itself is not synchronized reading while the equals method if that synchronizes access to them.

Two questions:

Any idea because the equals method is synchronized?
Under your view that there is such a problem is detected FindBugs?

Excuse my poor English and thank you.

By: Anonymous

Anonymous — Sat, 16 May 2009 23:14:30 +0000

@Michael B: Yes, this series is about programmer errors ie bugs. I’m not trying to suggest anything is wrong with Java. Not sure how you got that idea?

Sorry spend too much time with ppl who think they found bugs while it’s just there lack of understanding, guess it made me ‘twitchy’.

By: Alex

Alex — Thu, 14 May 2009 18:39:29 +0000

@Anton: The last example is thread-safe. No other thread can see the map until construction completes and at the end of construction final field freeze occurs such that other threads that get this instance of Stooges are guaranteed to see all objects reachable from stooges at the time of freeze, even without synchronization.

You don’t need to delay assignment because no one else can see the field. You should consider subclasses though which will have access to the field during their own construction and they could unsafely publish the map or “this”, ruining the semantics we’re trying to achieve. You could address that by moving the field initialization into the constructor or making the class final.

By: Anton

Anton — Thu, 14 May 2009 17:02:28 +0000

Is it guaranteed that the code in the last example is thread-safe? Should not we first populate the map and only then assign it to the field?

Sorry, didn’t sign the first one