commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Thread-safety of Commons-Codec Encoder
Date Wed, 02 May 2012 19:42:41 GMT
On 2 May 2012 20:16, David Smiley (@MITRE.org) <DSMILEY@mitre.org> 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: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message