commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Pugh <>
Subject Re: codec - thread safe
Date Mon, 08 Oct 2007 16:26:26 GMT
David J. Biesack wrote:
>> Date: Mon, 8 Oct 2007 17:01:02 +0200
>> From: =?iso-8859-1?Q?J=F6rg_Schaible?= <>
>>> The java.util.concurrent backport
>>> runs on 1.3, for just this
>>> kind of use. 
>> I know this, but I doubt that we wanna start to depend Apache common components on
it ;-)
> Agreed; I, like you, was merely suggesting to what Commons consumers might do to deal
with non-threadsafe codecs.
Might seem like a silly question, but has anyone found anything that 
looks like a threading issue in Codec? 

The code is pretty simple.  I did a quick look through the code, and it 
seemed like everything was pretty thread safe.  It looks like you should 
be O.K. as long as:
    1)  You don't change the parameters to a codec while it's running, 
e.g. changing charsets, etc.
    2)  You should not use a MessageDigest returned by DigestUtils by 
multiple threads.  This should be clear given the API (it's a SUN api)

It also seems to me that the difference between code that you can trust 
as being thread safe, and code you cannot trust as being thread safe has 
a lot to do with whether it is tested for thread safety.  Seems to me 
like another way of helping out here would be to build concurrency tests 
for whichever APIs you are interested using on multiple threads.  Not 
sure where we would put them yet, but seems like the only way to assure 
thread-safety (especially if we could get someone to volunteer running 
them on a big beefy multi-proc machine :).
>> - Jörg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message