[stringtemplate-interest] Synchronization error in ST implementation.

[Zenaan Harkness]

On Tue, Sep 19, 2006 at 05:16:39PM -0700, Terence Parr wrote:
> On Sep 18, 2006, at 7:56 PM, Zenaan Harkness wrote:
> 
> > Here's a thought I have. From the doco for ST:
> >
> > "made static maps in STG synchronized, also synchronized the look  
> > up/def methods for templates in STG"
> >
> > Well, this is not technically an error, but why does ST synchronize?
> 
>    Because multiple threads can be adding looking up and adding  
> things at the same time.
> 
> > Surely the user should synchronize, if needed, so that everyone
> > else does not pay the price of locking.
> 
>    It's not easy to wrap everything in ST in something that will  
> synchronize it from outside; well I haven't looked into that, but  
> speed is not seem to be a problem for me.  Anybody noticed a problem  
> so far?

It's not so much about speed, it's that a couple of synchronized
statements may well not be what's needed.

To require the user to arbitrate access from multiple threads is
one simple solution, and offers best performance for those who
don't need the locking.

To provide alternate implementations requires more work of course.

For someone wanting a slashdot-sized site to use Stringtemplate,
the user of ST (the developer) is going to want fine grained
control of locking to maximize performance, and in many cases
might simply do away with locking altogether, and simply have a
pool of ST resources (STGroups, whatever). For this to work, all
statics must be removed, in general, and clearly specified
dependencies are required, in order to know what the  underlying
object graph is that you are working with.

In any case, a clear spec/ understanding of the related pieces is
very useful when implementing some or another locking solution.

A simple and failsafe starting point is:
- no locking by ST itself
- no statics inside ST - everything dynamic, although of course
  use Singleton pattern everywhere that makes sense

This will mean that ST clients can simply duplicate a hierarchy
and no that there are NO dependencies between the two copies,
and simply have a separate hierarchy for each thread/servlet/
whatever.

* Certainty is essential.

* Simplification is desirable.

* Locking is best avoided where at all possible, and more
  importantly than for performance, in order to minimize deadlocks.

* A simple global ST-access lock is easy for clients to implement.

* Remove all statics (in general) and provide a deep-copy to allow
  clients to readily create thread-independant instances, and
  therefore scalability (of the view generation code) to your
  hearts content.

Anyone writing a multi-threaded server will presumably have a
grasp of threading issues to start with, and will be in the best
position to know which strategy is best for their system anyway
(eg. separate "deep copy" ST instances with no interdependencies,
vs finer-grained locking and shared ST instances).

(I have spent a few years, on two separate projects, developing
multi-threaded server software.)

Regards
Zen

-- 
Free Australia - www.UPMART.org
Please respect the confidentiality of this email as sensibly warranted.