> I would look at the issue differently:
> Volatile reads can only be hoisted out of loops if doing so is not
> observable. This can happen for example if the JVM can prove that the
> variable is never concurrently written. That may happen if the code writing
> it can provable never be executed. And that might happen because we have a
> scheduler that never preempts a running thread. It's not at all clear to me
> that the semantics needs to talk about any of this; hoisting the volatile
> was legal only because it was invisible. I think this needs to be reflected
> in the semantics only in that runnable threads are not guaranteed to make
> progress, at least not if there is another runnable thread.
I now see that Hans is right: There is no need to mention hoisting in
If there is ever a JSR on revising scheduling specs in Java, it will
need to address JMM aspects though.
Also, it looks like the Real-Time spec (RTSJ JSR-1) which does specify
scheduling, will need to deal with this issue separately.
-- Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA firstname.lastname@example.org 315-312-2688 FAX:315-312-5424 http://gee.cs.oswego.edu/ ------------------------------- JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:35 EDT