Jeremy Manson wrote:
> I am going to display my ignorance here: is acquiring a
> lock when invoking getClass() mentioned anywhere in the spec?
:) That's why I said "assumes".
> Also, it wouldn't help even if a lock were acquired when invoking
> getClass() and before the invocation of getInstance(). There is no
> guarantee that the acquire of the lock by the reader thread
> will happen after the release of the lock by the writer thread. The
> reader could grab its lock first. Then there would no unlock / lock
pair
> between the initialization of the fields and reads of them by the
reader
> thread.
Right - the internal lock, even if present, does not lock the
assignment to initialized.
But my understanding of what Srinivas was doing was wrong anyway - he
was simply trying to do something that he thought would prevent the
reordering of the two statements, by introducing an apparent data
dependency.
But what Srinivas also apparently missed is the fact that object
allocation and invocation of the constructor is two separate actions -
allowing for more possible reorderings. But even if things were not
reordered at the Java level, the hardware could still reorder the
memory writes such that instance is not null and initialized is true,
but some of the writes made during the construction of the singleton
have not yet made it to main memory.
David Holmes
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:51 EDT