Re: JavaMemoryModel: Code that sleeps and expects to see changes

From: Bill Pugh (
Date: Mon Oct 25 1999 - 10:00:06 EDT

> > The question is what does sleep do? Is it simple a most cost
> > effective way of waiting for a certain number of milliseconds than a
> > timing loop, or does it has synchronization semantics?
>Again, I strongly suggest using the tactic I pursued in
> Describe the effects
>of sleep and join in terms of Object.wait. Object.wait has clear
>synch requirements.

Overall, I found this write up very useful and tried to incorporate
ideas from it in my odds and ends note.

> This approach does not force a particular
>implementation; it merely says that any real implementation cannot be
>distinguished from the one defined in terms of wait. This led me to
>write it as:
> An invocation of method Thread.sleep(long millisecs) is not guaranteed
> to be behaviorally distinguishable from the action:
> if (millisecs != 0) {
> Object s = new Object();
> synchronized(s) { s.wait(millisecs); }
> }
> Note that s is an object that is not otherwise used in any
> way. Thread.sleep(long millisecs, int nanosecs) operates identically
> except for accommodating nanosecond timing arguments.

This example is something of a problem. Under the old memory model
and with this semantics for sleep, a sleep loop without explicit
synchronization is guaranteed to work. Using my proposed memory model
and the above semantics for sleep, a sleep loop without explicit
synchronization would not work.

The problem is that under the old memory model,

        synchronized(new Object())

was guaranteed to be a global memory barrier, while under my proposed
memory model is it a no-op. Under my proposed semantics, Doug's
definition of sleep is exactly equivalent to looping until a certain
number of milliseconds has passed; no memory barriers need be done.



JavaMemoryModel mailing list -

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