commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Qingtian Wang" <qingtian.w...@gmail.com>
Subject Re: codec - thread safe
Date Sun, 07 Oct 2007 04:31:19 GMT
Well, it's pick-your-poison kind of a deal. Either block on one
instance and take a performance hit, or burn up the memory with lots
of instances.....

But in the case of BCodec, I think encode/decode is thread safe.
Unfortunately per Henri, that's not generally true for others.

Well, let me make it clear that I am a total layman on codec. But it
seems to me it's not that difficult to implement all the codec methods
in a thread safe manner, without sync blocks.

Can the dev team make that happen? - a humble request from a user.

Thanks,
-Q




On 10/6/07, ben short <jamin.short@gmail.com> wrote:
> How about...
>
> MyStringCodec {
>    BCodec delegate = new BCodec();
>
>    String encode(String in) {
>
>        String result = null;
>
>        synchronized(delegate)
>            {
>            result = delegate.encode(in);
>            }
>
>        return result;
>
>    }
> }
>
>
> On 10/6/07, Qingtian Wang <qingtian.wang@gmail.com> wrote:
> > Henri,
> >
> > That was an unpleasant surprise.
> >
> > So what would be the general suggested program pattern to use the API
> > if one wants to be thread safe?
> >
> > Is it 1:
> >
> > MyStringCodec {
> >     String encode(String in) {
> >         return new BCodec().encode(in);
> >     }
> > }
> >
> > or 2:
> >
> > MyStringCodec {
> >     BCodec delegate = new BCodec();
> >
> >     String encode(String in) {
> >         return delegate.encode(in);
> >     }
> > }
> >
> > Option 2 apparently won't work in a multi-thread scenario if BCodec is
> > thread unsafe. But option 1 really creates A LOT of BCodec objects in
> > memory....
> >
> > -Q
> >
> >
> >
> >
> > On 10/5/07, Henri Yandell <flamefew@gmail.com> wrote:
> > > On 9/29/07, Qingtian Wang <qingtian.wang@gmail.com> wrote:
> > > > I apologize for this question as it must have been asked a million
> > > > times: I was unable to search the mailing list archive for this.
> > > >
> > > > Are all the "encode/decode" methods in commons-codec intended to be thread
safe?
> > > >
> > > > I peeked into the source code for a couple of those methods. They both
> > > > seem to be thread safe. But I'd rather ask here to make sure that's
> > > > the general intention when the code is written.
> > >
> > > I think you'll find it varies. The various algorithms come from
> > > different sources, and though a common interface was put on them all,
> > > I doubt that time was spent to make sure they were all threadsafe.
> > >
> > > Looking at the objects, I see a few with private attributes that are
> > > set at more than just construction time - so very likely that one or
> > > another is thread unsafe.
> > >
> > > Hen
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
>
> ---------------------------------------------------------------------
> 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