Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Wed, 10 May 2006 00:13:00 -0700 (PDT)
From: Chris Hostetter <hossman_lucene@fucit.org>
To: Lucene Dev <java-dev@lucene.apache.org>
Subject: RE: Multiple threads searching in Lucene and the synchronized issue.
 -- solution attached.
In-Reply-To: <LMENLAOACIBLMOIILNNNEELJFNAA.rengels@ix.netcom.com>
Message-ID: <Pine.LNX.4.58.0605100005540.20473@hal.rescomp.berkeley.edu>
References: <LMENLAOACIBLMOIILNNNEELJFNAA.rengels@ix.netcom.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


: 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...

http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#dcl


: -----Original Message-----
: From: Chris Hostetter [mailto:hossman_lucene@fucit.org]
: 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
: : SHOULD PROBABLY work.
: :
: : 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.


-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org