commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (@MITRE.org)" <DSMI...@mitre.org>
Subject Re: Thread-safety of Commons-Codec Encoder
Date Thu, 03 May 2012 18:45:32 GMT

On May 3, 2012, at 2:30 PM, Julius Davies [via Apache Commons] wrote:

> > So if we agree that the Encoders that exist are thread-safe (as we've defined it)
and that they should be in general, then I plan to treat them that way in Lucene. 
> 
> 
> I guess you're saying you'll do this: 
> 
> Pattern #1:  save some memory, lose some thread safety 
> --- 
> public class MyClass { 
>   private static Encoder E = new Encoder(); 
> 
>   public void myMethod() { 
>     // need to encode or decode for some reason: 
>     E.encode(stuff); 
>   } 
> } 
> --- 

Sure.  There's the possibility of a static block configuring the encoder too.  Of course,
this same pattern could be realized without using 'static', but static is a concise way of
demonstrating a happens-before relationshipo in example code.  Another would be a volatile
instance variable that is only set after the encoder is configured.  And I assume myMethod()
is going to be invoked concurrently on the same MyClass instance by multiple threads.

> 
> Instead of this? 
> 
> 
> Pattern #2:  lose some memory (temporarily to hold encode table), gain 
> some thread safety: 
> --- 
> public class MyClass { 
>   public void myMethod() { 
>     // need to encode or decode for some reason: 
>     new Encoder().encode(stuff); 
>   } 
> } 
> --- 
> 

Right; not that.

> 
> Base64 definitely requires pattern #2, but the others appear to be 
> less complex, and might be okay. 

I've seen people say that Encoders should be made to be threadsafe and documented as such.
 I've not heard a dissenting opinion to this proposal.  So if Base64 can't work in pattern
#1, I suggest this be rectified.  All the phonetic encoders appear to be thread-safe already.

> Interesting dilemma.   As an (inactive) codec developer, I prefer 
> pattern #2 because it means less work for us, but, at the same time, 
> there is no way to force developers to go with pattern #2 (even if we 
> documented developers might not read it) and so coding defensively 
> over here in case developers pick approach #1 could result in less 
> work for us in the long run (fewer weird race condition bugs filed in 
> Jira?). 
> 
> 
> Mostly talking to myself here. 
> 

~ 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-tp4600956p4606799.html
Sent from the Commons - User mailing list archive at Nabble.com.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message