> Isn't my sentence which you quoted above exactly what happens
> on the Alpha? A thread uses a value from its own working memory, which is
> older than the value in main memory?
In the general case yes. But now we are distinguishing between what the spec
allows and what a naive implementation on a weakly ordered SMP might allow.
I don't read Ch17 as being so loose as to allow the first read of main
memory for a variable to happen an arbitrary amount of time prior to the use
of that variable - but the point is moot.
> No, there's a big difference. In your code above, it's
> possible for the write of the variable "helper" to arrive at the main
> before all of the writes performed by the constructor have arrived.
In that case can't you have three flag values:
- must use sync
- can use unsync if writes are not reordered
- can use unsync always
> I think you're describing something that can't happen.
> Neither of the two Booleans in my code ever changes from "true" to
> A thread can see a stale "false" value, but a stale "true" value is
> impossible. The new memory model won't drop the "not out of thin air"
> will it?
My understanding, and I'm sure Bill or Doug or someone, will correct me if I
am wrong, is that a variable accessed without synchronization, that is not
volatile, or accessed via a volatile or final ref, is allowed to take on any
value including garbage. The main example here is, as before, reading a
value that happens to be cached, but where the cached value does not
represent a value ever written to that variable.
> I'm not sure I understand what you mean. I was trying to say
> that if you write some code that takes advantage of the new volatile
> semantics, you will also have to provide a way to switch back to using
> synchronize, if you want your code to be able to run on old JVMs as well.
Sorry I misunderstood.
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:29 EDT