Re: JavaMemoryModel: Problem with Thread.sleep

From: Joseph Bowbeer (
Date: Mon Oct 25 1999 - 02:55:45 EDT


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 <> To: <> 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 -

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