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.
Bill
At 12:03 AM -0500 1/18/04, Bill Pugh wrote:
>OK, I don't have a formal proof that allowing 5 and 10 would cause
>the roof to collapse.
>
>But here is an example that gives me the willies:
>
>Initially, x = y = z = 0
>
>Thread 1
>r1 = z
>r2= 42 // really assume this is really a call to allocate
> // and initialize an object, and 42 is a reference to that object
>if r1 == 1
> x = r2
>
>Thread 2
>z = 1
>
>Thread 3
>r3 = x
>y = r3
>
>Thread 4
>r4 = y
>x = r4
>
>Scary behavior:
> r2 == r3 == r4 == 42, r1 == 0
>
>OK, the problem here is that from the viewpoint of thread 1, it sure
>looks like in the cases where r1 == 0, the object allocated in
>thread 1 is thread local, and it can freely allocate it in thread
>local storage and reclaim it immediately after it is no longer used
>by thread 1.
>
>However, I believe that Sarita's model would allow threads 3 and 4
>to get a reference to the allocated object, even in the case where
>r1 = 0.
>
>This scares me.
>
>Bill
>-------------------------------
>JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
-------------------------------
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