lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eyal Post (JIRA)" <>
Subject [jira] Commented: (LUCENENET-181) Port of ThreadLocal is wrong?
Date Mon, 20 Apr 2009 08:33:47 GMT


Eyal Post commented on LUCENENET-181:

you are saying that "ThreadLocal" is used as a syncronization primitive between threads. If
true, then Lucene.Net works as expected. 
Not as a synchronization primitive but as a way to make sure each thread gets a different
instance of the enum.

ThreadLocal instances are typically private static fields in classes that wish to associate
state with a thread

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

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message