> The semantics of final, as described in "Semantics of Multithreaded Java",
> leaves me confused as to how the proposed semantics fix the immutable String
> problem. It is unclear whether the correct use of final with immutable
> objects, is that the reference to shared immutable objects must be final, or
> whether the immutable object must utilise final fields.
In the string case, the reference to the array of characters and the
offset have to be final. As long as no references to the string escape
the constructor (which they don't), then it is required that any thread
which reads the String is going to see those fields as being up to date as
of the end of the constructor.
In the case of the String problem, the offset is set as "4" in the
constructor. No thread can see an offset of "0".
I admit that this is not as clear as I would like it to have been in the
paper. I tried to add a paragraph somewhere which explained it a little
better (I don't have the paper on hand just this minute), but perhaps it
wasn't enough. I discuss it in more detail and I also discuss
implementation strategies in a paper which I wrote. Some revision is
being done, but hopefully it should be available to read by the end of the
week / beginning of next week.
Jeremy
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:31 EDT