At 9:34 AM +1000 3/11/02, David Holmes wrote:
>Jerry Schwarz wrote:
>> In Bill's example if we accept feature 2 then the optimization would be
>> disallowed. If we accept feature 2' then the example doesn't contain [fill
>> in the blank] so feature 2' doesn't apply and we can say (as I anticipate
>> Cliff will say) that any behavior is acceptable for code containing
>> unsynchronized references.
>
>Cliff Click wrote:
>> (1) Person writes junk code and gets bit. No big deal.
>
>I am concerned about the situation, where the two Runnable's represent
>distinct code written by distinct parties. If Person 1 writes the junk code
>and gets bit - that's fine by me. If Person 1 writes the junk code and
>Person 2 gets bit - that's not fine.
This is the essence of my concern.
Realistically, I do not believe we are going to be able to say that all code
that either
* stores a reference to "this" into the heap while "this" is being
constructed, or
* modifies final fields after objects are constructed
is fundamentally broken. There is just too much existing code that
does this (e.g., any code that creates an instance of a non-static
inner class in a constructor).
OK, since we must allow object references to be stored into the heap
while the objects are being constructed, then we need to have
"recommended and guaranteed" idioms for doing so.
So consider two code fragments, run in separate threads
F1) Construct an object, storing a reference to the object
into the heap before the construction is complete
F2) Accesses the constructed object, using the "recommended and
guaranteed" idiom
OK, now because a correct idiom was used for communication between F1
and F2, this code works. Now, the question is, can some completely
separate code fragment, F3, which also reads the reference exposed by
F1, cause F2 fail?
If so, I am worried about our ability to debug, analyze and
understand multithreaded software.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:38 EDT