[
https://issues.apache.org/jira/browse/LUCENENET-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700697#action_12700697
]
Eyal Post commented on LUCENENET-181:
-------------------------------------
{quote}
you are saying that "ThreadLocal" is used as a syncronization primitive between
threads. If true, then Lucene.Net works as expected.
{quote}
Not as a synchronization primitive but as a way to make sure each thread gets a
different instance of the enum.
{quote}
ThreadLocal instances are typically private static fields in classes that wish
to associate state with a thread
{quote}
The keyword here is *typically*. Yes, usually that's the way to use them but
it's not mandatory.
When they are static you get a different value per thread.
When they are not static you get a different value per thread and also per
instance.
> 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.
