-
-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Making a thread safe Collator #119
Comments
I assume you're familiar with http://userguide.icu-project.org/design. That mentions a So - no, I don't have any other ideas. Your suggestion of creating facade classes sounds good. I'm happy to accept a PR. Can you please share the results you get from running benchmarks? With the facade classes I guess the question with the property setters remains the same. Maybe we should implement something like Freezable? Then we could throw an exception in the setter if it's frozen. I haven't thought this through - just an idea that came to my mind. |
Thanks. I ended up porting the portions of ICU4J that are required by Lucene.NET: https://github.com/NightOwl888/ICU4N Unfortunately, this icu-dotnet has too many limitations for our needs, not just thread safety. For example, we need to use UnicodeSet as a filter. I attempted to implement the functionality, but it doesn't work. That said, there are some unfinished issues to deal with on ICU4N before it can be called stable, most notably:
What are your thoughts on combining our efforts on ICU4N? |
Is your feature request related to a problem? Please describe.
This is sort of a question/feature request.
First of all, it seems there is a difference in design between
icu4c
andicu4j
. The collator documentation clearly states thatHowever, the component I am porting that uses the
icu4j
RuleBasedCollator is able to store an instance as a private variable in a class and have that variable be hit by multiple threads at once.I tried using
lock (thisObj)
, but somehow the Collator knows that the wrong thread is calling it even if the call itself is synchronized. The only thing that works is creating a clone per thread, which is no help if you are not the one instantiating the threads.Describe the solution you'd like
What I would like to see is a thread safe Collator and RuleBasedCollator implementation out of the box. I was able to make this happen on my first attempt, but I am not sure how this will perform.
It works great, but I haven't yet benchmarked it to see how it performs without all of the additional cloning. I am also not sure about the property setters, but I only needed them in one class that was already deprecated in the code I am porting.
Describe alternatives you've considered
My second attempt was to try not to call
Clone()
so much in order to try to make it more efficient. At first I was thinking to try to store the collator in theThread
itself usingThread.SetData
, but without a local reference it would leave no way to dispose the collator.So, I tried making a local cache based on the thread id. Unfortunately, managed and unmanaged thread ids are 2 different things, and the latter requires a lower level call. However, this didn't seem to work (maybe I missed something, though).
Additional context
First of all, I am wondering if you have any other suggestion that might work.
Secondly, would you consider providing something like this? My thought is to rename the existing collator types, mark them internal, and provide facade classes with exactly the same interfaces and documentation comments as the originals. Thread safe could just be an option that is enabled with a constructor or creation method parameter. The constructor would load either the thread safe or non safe instance internally.
The text was updated successfully, but these errors were encountered: