jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Connor, Brett (LNG-TWY)" <Brett.Con...@lexisnexis.co.uk>
Subject RE: Extending SimpleWebDavServlet
Date Mon, 29 Sep 2008 08:32:14 GMT
Marc wrote:
> Hi Felix
> > I am neither an export on any Memory Model issue, but I always
> > 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
"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.


Registered in England - Company No. 02746621

View raw message