lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject RE: Multiple threads searching in Lucene and the synchronized issue. -- solution attached.
Date Wed, 10 May 2006 07:13:00 GMT

: That is not my understanding. My understanding is that volatile just ensures
: the JIT always accesses the var in order - prevents some compiler
: optimizations - where as synchronized needs to acquire the lock. (There were
: discussions regarding having volatile create synchronized accessors behind
: the scenes - but I don't think that semantic was ever agreed upon).
: That coupled with using primitives (to avoid the early memory alloc - since
: primitives are allocated on the stack), allows the double-locked
: synchronization to work (at least that is my understanding).

perhaps, I'm not expert i was just going based on what i've read, and
aparently i forgot to paste the URL in my last email...

: -----Original Message-----
: From: Chris Hostetter []
: Sent: Wednesday, May 10, 2006 12:51 AM
: To: Lucene Dev
: Subject: RE: Multiple threads searching in Lucene and the synchronized
: issue. -- solution attached.
: : I think you could use a volatile primitive boolean to control whether or
: not
: : the index needs to be read, and also mark the index data volatile and it
: :
: : But as stated, I don't think the performance difference is worth it.
: My understanding is:
:   1) volatile will only help as of java 1.5 ... lucene targets 1.4
:      compatibility.
:   2) in 1.5, volatile is basically just as expensive as synchronized.
: : I met these problem before indeed.The compiler did something optimized for
: : me that was bad for me when I see the byte-codes.
: :  When I'm using a function local variable, m_indexTerms and in JDK1.5.06,
: it
: : seems ok.
: : Whether it will break in other environments, I still don't know about it.
: The dangerous thing is that even if the byte code looks okay, and if it
: works okay today, your app could run for a while and then all of the
: sudden it could stop working because of the order the threads are run, or
: becuase of an optimization the JVM applies on the fly.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message