> > 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
>http://gee.cs.oswego.edu/dl/html/jvms.html: 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.
Bill
Bill
-------------------------------
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