[
https://issues.apache.org/jira/browse/LUCENENET-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700691#action_12700691
]
Digy commented on LUCENENET-181:
--------------------------------
As far as I can understand you;
you are saying that "ThreadLocal" is used as a syncronization primitive
between threads. If true, then Lucene.Net works as expected.
What makes me confused is the definition of "ThreadLocal":
*This class provides thread-local variables. These variables differ from their
normal counterparts in that each thread that accesses one (via its get or set
method) has its own, independently initialized copy of the variable.
ThreadLocal instances are typically private static fields in classes that wish
to associate state with a thread*
DIGY
> Port of ThreadLocal is wrong?
> -----------------------------
>
> Key: LUCENENET-181
> URL: https://issues.apache.org/jira/browse/LUCENENET-181
> Project: Lucene.Net
> Issue Type: Improvement
> Reporter: Digy
> Priority: Minor
> Attachments: TestCase.cs
>
>
> AFAIK, "ThreadLocal" in Java is there to hold objects which are intented to
> be used thread-wide. So, its port-equivalent "LocalDataStoreSlot" should
> contain objects related with the executing thread. But, since they are not
> declared as "static" in Analyzer.cs, FieldsReader.cs, SegmentReader.cs and
> TermInfosReader.cs, they are created with every class contruction, changing
> the behaviour of "ThreadLocal" and possibly resulting in performance
> degradation.
> I will attach a test case for this issue.
> If I am wrong, then there is no problem. But If I am right we are in trouble;
> Since adding "static" to variables declared as LocalDataStoreSlot results in
> failing of almost all test cases.
> DIGY
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
