Correct me if I misunderstand the string issue.
In order for the string object to be published, the object reference has
to be written to a globally visible location. If the global location
is declared as volatile, or protected by synchronization blocks then
things are OK because the required memory barriers are present.
If the location written is not protected in any way, still the model of
a single initialization thread followed by many Thread.start() should be
OK, because the memory barrier associated with Thread.start() flushes
the writes.
In the case of the location writen is not protected in any way, and
multiple threads immediately use it, this is a race condition. Under
this race condition, a reader may see string value that it is not supposed
to see because for example the 'offset' field may be read as 0.
To prevent this security violation, the string fields should be declared
as blank finals. The blank final declaration should ensure writes are
immediately flushed under the proposed memory model.
If we did not worry about the security violation, then the blank final
declaration need not be used; if we say it is OK for the racy thread
to read default field values.
-Thomas Wang (Software Engineer, Enterprise Java Lab)
wang@cup.hp.com http://www.concentric.net/~Ttwang
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:26 EDT