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. -----Original Message----- From: yueyu lin [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 09, 2006 11:32 PM To: java-dev@lucene.apache.org Subject: Re: Multiple threads searching in Lucene and the synchronized issue. -- solution attached. 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. On 5/10/06, Yonik Seeley <[EMAIL PROTECTED]> wrote: > > On 5/9/06, Robert Engels <[EMAIL PROTECTED]> wrote: > > I am fairly certain his code is ok, since it rechecks the initialized > state > > in the synchronized block before initializing. > > That "recheck" is why the pattern (or anti-pattern) is called > double-checked locking :-) > > -Yonik > http://incubator.apache.org/solr Solr, the open-source Lucene search > server > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- -- Yueyu Lin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
