As long as the value displayed is allowed to be wrong or inconsistent
you're fine :)
The 'fits in int' might hold true but doesn't have to - at a low
level in the memory controller it might only write 8 bits, (or 1 bit)
at a time. Cache consistency doesn't work as most people think it
should. Most of this is very architecture/hardware specific.
The value may be VERY STALE, but in practice, when making the cache
consistent across multiple processors it is usually done in bulk, so
any sync commands cause the entire cache to become up to date. This
will change in the future as processor pipelines and OS/JVM support
can be more fine grained.
Some good overviews on the subject:
http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html
http://gee.oswego.edu/dl/cpj/jmm.html
and the more complete reference...
http://www.cs.umd.edu/~pugh/java/memoryModel/
Bottom line, since the value is not used in any computations, you're
probably ok.
On Nov 29, 2007, at 1:41 PM, Mark Miller wrote:
I've been thinking about this and I think the situation we are in
is okay. The variable is an int and so should be read in one memory
access (i would think?). So at worst, the result might be stale?
Since this read is just for informational type purposes, (eg its ok
if this particular method returns a stale value, by the time you
read it its likely to have changed anyway), I think its okay.
I think. Everything I read about the Java memory model, I quickly
forget.
robert engels wrote:
FYI, any time one thread reads a value while another thread
updates it it needs to be synchronized, or with current JVMs a
volatile variable.
The Java Memory Model requires this.
Otherwise you can get a partial value (when the underlying value
requires more than one memory access to retrieve).
On Nov 29, 2007, at 6:43 AM, Mark Miller (JIRA) wrote:
[ https://issues.apache.org/jira/browse/LUCENE-1026?
page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel#action_12546702 ]
Mark Miller commented on LUCENE-1026:
-------------------------------------
Hey Mark, few more questions:
1. Why is StopWatch needed?
StopWatch could certainly be taken out. I simply used it for
timing...to show someone else that it doesn't take that long to
get an accessor. I have no problem with removing it.
2. No need to synchronize on this since you're only returning the
value, not performing any modifications to it.
Its possible this could be taken out. I doubt there would be any
noticeable trouble if you tried to read that value while another
thread was updating it.
3. open() - is there a real need to throw an exception if someone
called the accessor.open() twice?
No real need I suppose. I believe this came in from the original
code. I have no objections to taking it out.
SimpleSearchServer is an attempt to give an example that shows
how this code can be used to create a very simple class that
allows multi-threaded access to a Lucene index. I whipped it out
extremely quickly, but its something I would like to build on. It
can be nice to hide the IndexAccessor code behind a simple to use
class that hides Lucene and a lot of complexity.
Thanks for your work on this!
- Mark
Provide a simple way to concurrently access a Lucene index from
multiple threads
-------------------------------------------------------------------
-------------
Key: LUCENE-1026
URL: https://issues.apache.org/jira/browse/
LUCENE-1026
Project: Lucene - Java
Issue Type: New Feature
Components: Index, Search
Reporter: Mark Miller
Priority: Minor
Attachments: DefaultIndexAccessor.java,
DefaultMultiIndexAccessor.java, IndexAccessor.java,
IndexAccessorFactory.java, MultiIndexAccessor.java, shai-
IndexAccessor-2.zip, shai-IndexAccessor.zip, shai-
IndexAccessor3.zip, SimpleSearchServer.java, StopWatch.java,
TestIndexAccessor.java
For building interactive indexes accessed through a network/
internet (multiple threads).
This builds upon the LuceneIndexAccessor patch. That patch was
not very newbie friendly and did not properly handle
MultiSearchers (or at the least made it easy to get into trouble).
This patch simplifies things and provides out of the box support
for sharing the IndexAccessors across threads. There is also a
simple test class and example SearchServer to get you started.
Future revisions will be zipped.
Works pretty solid as is, but could use the ability to warm new
Searchers.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
--------------------------------------------------------------------
-
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]
---------------------------------------------------------------------
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]
