[stringtemplate-interest] ST in multi-threaded environment

[Terence Parr]

On Jul 11, 2006, at 12:12 AM, Oliver Flege wrote:

> Hi,
>
>> I don't think we have a threading issue...can somebody point out a
>> scenario?
>
> let me point you to some examples:
>
> In my web application, a StringTemplateGroup is created at startup  
> [servlet container main thread]
> StringTemplateGroup g = new StringTemplateGroup(name, rootDir)
>
> Every servlet that needs to render a page, uses that group (which  
> can be obtained from
> the ServletContext) as follows:
>
> StringTemplate st = g.getInstanceOf(templateName)

Makes sense so far...

> getInstanceOf invokes lookupTemplate, which uses the "templates"  
> Map: it might
> clear it, it calls get to lookup a template, and maybe put if it  
> had to load the template
> All of these actions are performed in the context of the servlet's  
> thread. So when the
> servlet container uses a thread-pool to run servlets (as most of  
> them do), the actions
> on the "templates" Map in StringTemplateGroup are performed by  
> multiple threads
> and without synchronization => threading issue, as HashMap cannot  
> cope reliably with
> multiple threads accessing it in parallel.

I see.  Yes, the group of templates could be unsafe due to caching.   
If all templates are loaded up front then this would be avoided I  
suppose.  Technically though you are absolutely correct.  Loading of  
templates is not safe.  Shall I wrap the Map in a thread-safety thing  
or just use Hashtable?

> Once st.write(...) gets called, an ASTExpr may need to access the  
> property of some object,
> so it calls StringTemplateGroup's getCachedClassProperty and maybe  
> later cacheClassProperty.
> Both of these static methods access the "classPropertyCache" static  
> Map, again w/o synchronization,
> although multiple servlet threads may invoke these operations in  
> parallel => another threading issue.

Yes, I just *knew* that would cause trouble...i'm thinking of taking  
out..not sure it's worth the complexity.

> StringTemplateGroup's attributeRenderers Map can be replaced or  
> renderers can be added to it
> without synchronization. If a servlet's thread later calls  
> getAttributeRenderer, again w/o sync,
> one would assume that it should be able to access those renderers  
> right away, but this assumption
> is plain wrong* => yet another threading issue.

That is an ordering issue.  The real issue is that a read thread  
could catch a write thread in the act of updating the data structure.
> => For each mutable state variable in both StringTemplateGroup and  
> StringTemplate that may be
> accessed by more than one thread, all accesses (not just writes,  
> also reads) should be performed
> with the same lock held, so that the variable is guarded by that  
> lock. Ideally, the documentation
> would state which lock has to be used for each variable (important  
> since there are so many protected
> variables that subclasses or other package level classes can access).

ST objects should be ok.  It's the group, as you point out, that has  
issues.

> I hope this clarifies my concers about ST's tread-safety.

it does, thanks!

> PS: I know I am somewhat picky about this issue, but we develop  
> heavily threaded systems for
> stock market data feed processing and neglecting thread-safety is  
> just not an option for us :)

I'm glad you're paranoid then!

Ok, i did this:

o made static maps in STG synchronized, also synchronized the look
up/def methods for templates in STG.

also added a comment on map defs:

	/** Define a map for this group; not thread safe...do not keep adding
	 *  these while you reference them.
	 */

Hmm...I should really do a heavy analysis on the whole STG thing...I  
use it now in a very diff env than the web where all templates are  
loaded via a group file.

How much are synchronized methods slowed down these days for  
uncontentious locks?  I'm worried that I just slowed antlr down.  Did  
I just kill performance?

Ter