At 12:10 AM 18/01/2004 -0500, Bill Pugh wrote:
>On thinking about this a little more, we may be protected from issues with
>JVM implementations, since the memory model is part of the JVM
>implementation; if the JVM is going to allow this weird behavior, it has
>to deal with the GC consequences. However, I think we also need to be
>scared about some user code being completely confident that the object
>allocated at address 42 was never shared with other threads, when in fact,
>other malicious threads have gained access to it.
Whereas in test case 17
Initially, x = y = 0
Thread 1:
r3 = x
if (r3 != 42)
x = 42
r1 = x
y = r1
Thread 2:
r2 = y
x = r2
it would be perfectly valid to infer that since r3 is not 42 after its one
and only assignment, there is no danger of the value 42 leaking as a result
of r3 being 42.
Yet r1 == r2 == r3 == 42 is a permitted outcome.
I can see that M/P permits one and not the other, but I would be hard put
to say that one is expected, and the other unexpected. In truth, most
developers would probably not expect any of the outcomes permitted in the
test cases.
One thing is very clear to me - developer's will have to learn that if
they're going to write data races into their programs they have to have a
very deep understanding of whatever model is eventually adopted. The
corollary is that you can't appeal to developer's expectations to prefer
one model over the other.
Sylvia.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:56 EDT