Marc wrote: > > Hi Felix > > > I am neither an export on any Memory Model issue, but I always thought > > that the construct > > > > fieldX = new SomeType(zzz); > > > > would be ok, because fieldX would only be set after the SomeType > > instance has properly been setup and ready for use. > > > I would have thought the same if I had not learned it differently... again, there is some black magic in the > Java air ;) I do not understand this mechanism in the memory model but I would be thankful if someone could provide an explanation.
The statement you make above only holds true within the single thread running this code. The issue is updating state between private thread memory in the JVM. One of the things that 'synchronized' does as well as the more obvious acquiring the object monitor, it provides what they call a memory check or memory gate or something - a signal to the VM to sync changes in this thread with the global memory space. Without this there are no guarantees that the updates are in the write order AFA other threads see them. For example the reference to the object may be visible but the object itself may not be initialized. Google for "double check locking unsafe" I think you'll find some better descriptions. "Volatile" helps but as was said earlier it was broken until recent VMs. Have a read of JSR 133 (I think) - it's a bit of a mind bend! > > Have you encountered a concrete problem with this or is a pure > > academic discussion ? > > > > This is pure academic, but I crunch multi-threading bugs rather on this level than tracking bugs that just happen "now and then". I agree. I've seen issues with Jackrabbit clustering for example that may be down to this kind of thing but very hard to track down. Brett REED ELSEVIER (UK) LIMITED - Registered office - 1-3 STRAND, LONDON WC2N 5JR Registered in England - Company No. 02746621
