You are correct. It would seem that modern processor architecture will provide a better solution to this. Since they seem to be giving up on clock-speed and going with multiple parallel cores, and multi-processors, making a solution to this problem of even greater importance. The upside should be that JVMs will be able to implement synchronized more efficiently.
-----Original Message----- From: Yonik Seeley [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 10, 2006 10:07 AM To: java-dev@lucene.apache.org; [EMAIL PROTECTED] Subject: Re: Multiple threads searching in Lucene and the synchronized issue. -- solution attached. On 5/10/06, Robert Engels <[EMAIL PROTECTED]> wrote: > 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. No, that still doesn't work. volatile doesn't quite mean what you think it means with the Java memory model < v1.5. Reads and writes of volatile variables may not be reordered, *but* non-volatile reads & writes may still be reordered w/ respect to the volatile ones (making volatile not-that-useful). The *reference* to the object is really the only thing that becomes consistent across threads... the fields of objects the reference points to can be inconsistent unless all the fields are volatile. The memory model changed in Java1.5, and the meaning of volatile along with it. -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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
