Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Users List" <user@commons.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Date: Thu, 3 May 2012 11:45:32 -0700 (PDT)
From: "David Smiley (@MITRE.org)" <DSMILEY@mitre.org>
To: user@commons.apache.org
Message-ID: <0251C0D0-EDE8-474F-92FC-5A8F655A01E1@mitre.org>
In-Reply-To: 
 <CANNF_P1RioN-KMR1hHm5Syy6RUf3gs-cRhakN_NB+tqP3TK3RA@mail.gmail.com>
References: <1335885808555-4600956.post@n4.nabble.com>
 <4FA17A90.8040907@gmail.com>
 <CAOGo0VZ8tOJBcHtz3KXLuq-Sx3HiU9po1iYX9paX0UYdqVMWow@mail.gmail.com>
 <1335986186062-4604182.post@n4.nabble.com>
 <CAOGo0VY0qsG2a1UnehFAm4sy6q1s_PRJpYq1=4Jcvzprch728g@mail.gmail.com>
 <437E21F1-5556-4A15-8858-37671C348BF1@mitre.org>
 <CANNF_P1RioN-KMR1hHm5Syy6RUf3gs-cRhakN_NB+tqP3TK3RA@mail.gmail.com>
Subject: Re: Thread-safety of Commons-Codec Encoder
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_133527_20708891.1336070732609"

------=_Part_133527_20708891.1336070732609
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


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.
------=_Part_133527_20708891.1336070732609--