commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject RE: codec - thread safe
Date Mon, 08 Oct 2007 11:29:29 GMT
simon wrote on Monday, October 08, 2007 8:19 AM:

> On Sun, 2007-10-07 at 15:23 -0500, Qingtian Wang wrote:
>> Ok, I got the point.
>> So let's say I wanted to work on this. What's the most effective way
>> to do it? 
>> Search the entire code base line by line trying to ID all the thread
>> unsafe points by myself? I guess that's very ineffective compared to
>> have an issue open, and have the individual developers who write the
>> code to address it - They know what needs to be tweaked without
>> having to even spend any time since it's their own code. Or at
>> least, the dev team as a whole can come up a list of points that
>> need to be worked on. I think that'd be much more effective. Any
>> established channel where that can happen?
> I would suggest that you just check the classes/methods that you
> yourself want to be threadsafe, and make any necessary fixes.
> There's no obligation to fix anything else; if somebody needs
> thread-safety improvements in a different part, then *they* can do it.


Well, I don't think that this solution is really good. Either codec classes are supposed to
be thread-safe or not. A  solution where some are and other are not is probably not what is
expected. Why not simply go with the JDK Collections approach and provide a CodecUtil with
static methods for synchronizedEncoder(), synchronizedStringEncoder(), synchronizedBinaryEncoder
and the corresponding methods for the decoders? So everyone can decide on its own whether
he need synchronization or takes a pool approach in case of concurrency.

- Jörg

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

View raw message