Sean,
The current JMM - as defined in JLS Ch. 17 - does not guarantee the
correctness of your cache because the current JMM allows writes to be
re-ordered. For example, the reference to the new cache entry may be written
to main memory before the fields of the entry are written. This may lead to
a null pointer exception in the snippet below if the reading thread sees sce
!= null but does not yet see sce.key != null. Or it may lead to an incorrect
result if the reading thread sees sce != null and sce.key != null, but it
does not yet see sce.value != null.
> // our single allowed load.
> SinCacheEntry sce = this.cache[key.hashCode() % this.cache.length];
> if (sce != null) {
> if (sce.key.equals(key)) return sce.value;
> }
Whether the new JMM will or should guarantee the correctness of your
implementation, I leave for others to answer. I know Josh Bloch's proposal
addresses this, and Bill Pugh wrote:
"This memo doesn't include anything about safety of object construction
or of final fields (the kinds of things we need for String) -- those will be
added later."
-- Joe Bowbeer----- Original Message ----- From: Sean McDirmid <mcdirmid@cs.utah.edu> To: <javaMemoryModel@cs.umd.edu> Sent: Sunday, October 24, 1999 10:29 PM Subject: Re: JavaMemoryModel: Problem with Thread.sleep
> Assuming that sin_impl is thread safe, I'm willing to say that the method > doit should also be thread safe (at least under some reasonably safe > model). This is without any synchronization at all. > > Are my assumptions reasonable? I'm working with cases that must remain > atomic with no synchronization. > > - Sean >
------------------------------- JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:21 EDT