[stringtemplate-interest] thread safety

[Terence Parr]

On Nov 13, 2009, at 7:17 AM, Oliver Flege wrote:
>> so, currently in ST v3, only renderer tracking is thread safe
>> All the other stuff isn't; not even adding attributes. the question
>> is: what should be thread safe. seems weird to have multiple threads
>> update a single template or group, but...thought i would ask.
>
> the typical approach in a multithreaded environment (rendering web  
> pages)
> would probably be to create a shared StringTemplateGroup(-hierarchy)
> used by different threads to obtain the templates to be rendered.

yep, that should be safe as long as you don't define templates as you  
run the webserver.

>
> So in StringTemplateGroup you need to synchronize access to all shared
> datastructures that might get updated while templates are being  
> rendered,
> in particular the "templates" Map.

Rather than slow thingdown with a lock; i think people can just avoid  
an update or sync themselves.

> When threads obtain a template from a shared StringTemplateGroup,
> they _must_ call getInstanceOf(...) and not lookupTemplate(...).

lookupTemplate in new version returns shared CompiledST prototype not  
an ST.

> getInstanceOf(...) ensures all threads end up
> with their private copy of the template that they can update as
> needed (without needing further synchronization).
>
> Perhaps the javadoc should state explicitly that getInstanceOf(...)
> is intended for multi-threaded use and lookupTemplate is not.
>
> BTW: the DateRenderer you announced recently implicitly relies on
> the fact that DateFormat.get...Instance(style) does _not_ return the  
> same
> object for the same style. If it would (which we cannot control and
> which could change with any jdk update), calling f.format(d) would
> not be thread safe as DateFormat ist not thread safe.
> synchronized(f) {return f.format(d);}
> would therefore be safer.

it's readonly. why would we need to sync?
T