Not to doubt Paul, but have others been able to replicate the problem?
(If we are going to mention this in our JavaOne talk, I'd prefer to
have replication).
I observed the problem on a Windows NT machine with 2 processors, but
was not able to observe it on my Windows 98 (uniprocessor) laptop.
I've not been able to observe it on a Sparc, or under HotSpot.
Thread context switching usually (always?) provides a sequentially
consistent memory model, so my guess is the same as others: that
compiler optimization and code generation must be reordering the
writes.
I made a few changes to Paul's code:
- eliminated duplicate reads - makes code faster, thus more likely
to detect problems, also eliminated confusing messages when
log reports that a field was seen unitialized, then prints the
initialized value
- added a catch up feature, so that if two threads get out of sync, the
slower thread jumps up to the most recently created singleton.
I've attached the modified code.
Bill
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:26 EDT