On 2 May 2012 20:16, David Smiley (@MITRE.org) <[email protected]> wrote: > The "kind of thread-safety" I would expect and want is for Encoder.encode() > to be thread-safe. I should be able to instantiate and configure an > Encoder, then share it for multiple concurrent threads to use to call > encode() as many times as they please at the same time. I will assume it is > up to me (the client/user of the API) to arrange for a happens-before > relationship between instantiation/configuration and the encode() call, by > using any one of a variety of means of doing so. This is kind of a given > but I want to be clear.
That is necessary for safe publication, but not sufficient if the class changes the values of any instance variables as part of the encode() processing. In the case of Metaphone#setLength(), the variable is not volatile, so is not inherently thread-safe. Provided that you set the length once initially, and used suitable means to publish the instance to the different threads, it would then be safe to use from multiple threads, so long as setLength() was not called again. So you would need to create separate instances for each length. I'm not sure it would make sense to share an instance between multiple threads and then change the length in one thread, so the fact that the length variable is not volatile really only affects how the instance needs to be shared initially. So I think you can say that the Metaphone class is conditionally thread-safe. > I haven't looked at any of the source behind the Encoders, but one area that > may be problematic is any lazy-instantiation/initialization of state to > instance variables in a non-thread-safe manner by the encode() method. If > Encoder had an init() method as part of its api, it would be easy to avoid > this problem but alas, it doesn't. A public init() method is but one way to do this, and would not help where there are setters. [Well, I suppose the init() commmand could "freeze" any mutable values] > FYI a good book on this tricky stuff is "Java Concurrency In Practice" by > Brian Goetz. Yes, I've read it. > ~ David > > ----- > Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book > -- > View this message in context: > http://apache-commons.680414.n4.nabble.com/Thread-safety-of-Commons-Codec-Encoder-tp4600956p4604182.html > Sent from the Commons - User mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > 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]
