[stringtemplate-interest] thread safety
Oliver Flege
o.flege at market-maker.de
Fri Nov 13 07:17:40 PST 2009
Hi,
> 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.
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.
When threads obtain a template from a shared StringTemplateGroup,
they _must_ call getInstanceOf(...) and not lookupTemplate(...).
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.
--
Oliver
More information about the stringtemplate-interest
mailing list