commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Will Pugh (JIRA)" <>
Subject [jira] Updated: (CODEC-55) make all "business" method implementations of public API thread safe
Date Tue, 09 Oct 2007 18:14:50 GMT


Will Pugh updated CODEC-55:

I have no problem changing the name "createThreadSafeCodec" to whatever you want.  I thought
codec was safe, since that is in the package name and the project name.  The fact that RefinedSoudex
is not a decoder is not important enough to have a separate package (org.apache.commons.encoders???),
so I figured it was not important enough to stray from consistency.

The problem this is looking to solve is to merge "documentation" of thread safety with the
ability of getting thread safe objects.  Having to have multiple instances of encoder/decoders
for different property combinations is an orthogonal issue to thread safety.  This fix just
protects the user from breaking their own thread safety by changing encoding parameters while
other threads are using them.  Doing so is just not thread safe (at least not in a way we
can reasonably protect against in codec).

1)  You cannot simply use synchronization, for the obvious reasons that two threads can override
their own setting variables (and that it would be unnecessarily slow)
2)  Using ThreadLocal storage for each parameter will cause strange problems in any case where
a codec is handed across threads.  This can happen
    a)  If someone creates a singleton for everyone to use (in the common case where an app
is only using one encoding/combination of properties)
    b)  If someone is creating a map to manage their own codecs (in the case that they are
worried about this, and have built their own maps (I think this is definately a possibility
for existing code))
    c)  In an app where there are many worker queues

If you have have a case where you have actively many combinations, I think the best solution
to use thread local storage for each codec/encoder/decoder itself, and then don't use thread
safe ones.  This way, you have less TLS lookups.  In actuality, simply allocating/deallocating
in these cases is probably fast enough as well

> make all "business" method implementations of public API thread safe 
> ---------------------------------------------------------------------
>                 Key: CODEC-55
>                 URL:
>             Project: Commons Codec
>          Issue Type: Wish
>            Reporter: Qingtian Wang
>         Attachments: concurrentCodecs.diff, concurrentQDiff.diff, urlcodec.patch
> Maybe most of the implementations are already thread safe. Just such that codec can say
so in general...

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message