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

From: Doug Lea (dl@altair.cs.oswego.edu)
Date: Mon Oct 25 1999 - 10:51:12 EDT


> 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.

Note that the synch is needed to do the wait, in:

> if (millisecs != 0) {
> Object s = new Object();
> synchronized(s) { s.wait(millisecs); }
> }

But I don't understand the sense in which you mean that it was a
global barrier under old model. If thread A sleeps, and then looks at
a field that was modified by thread B, but thread B has not released a
lock, then thread A may still be seeing old value.

The only difference here is that under the new model, it is clear that
this field would need to be read and written under the same lock (or
else declared volatile). But it is very hard to imagine someone
writing synched versions that did not use the same lock here . Using
different locks would be weird and dangerous. I cannot offhand
remember ever writing or seeing any Java code that did anything like
this.

-Doug
 



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