For what its worth...

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

-----Original Message-----
From: Chris Hostetter [mailto:[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to