RE: JavaMemoryModel: Tiger beta1 ConcurrentHashMap bug?

From: Doug Lea (dl@cs.oswego.edu)
Date: Fri Apr 09 2004 - 08:08:13 EDT


> For this to work correctly it is the shared *reference* globalC that must be
> correctly synchronized: globalC must be final, volatile, or else set and
> read whilst holding a monitor.

In general, ANY instance of a class that internally uses locks or
volatiles inside a constructor that must complete before the object is
used must be accessed by a ref that is final, volatile, or accessed
within locks. where in turn, these locks must have this property.
("synchronized(this)" is always OK because "this" is implicitly
final.)

I suspect that a lot of people will get this wrong, and won't even
notice that it is wrong.

It would be possible to counteract this by extending rules to require
order preservation of writes of refs to new objects initialized in
constructors that include not only finals, but also locks and/or
volatile writes.

Another approach is to make tools like findBugs detect such cases
to help programmers avoid such situations.

-Doug

-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel



This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:02 EDT