[stringtemplate-interest] Synchronization error in ST implementation.

[Zenaan Harkness]

On Wed, Sep 20, 2006 at 12:35:46PM +1000, Zenaan Harkness wrote:
> * 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.

Another point:

* Performing some synchronization within ST, is no guarantee that
  clients will not have to synchronize anyway, thus incurring
  unnecessary additional synchronization overhead. See issues of
  "conditional thread-safety" and having to 'externally' synchronize
  on "sequences of operations". See article 2 below.

Potentially useful URLS:

1) "Check out three collections libraries" talks a little on synchronization.
http://www.javaworld.com/javaworld/jw-11-2002/jw-1101-collections-p2.html

2) Classic article here, conditional thread safety of supposedly
   synchronized containers, collection-wide lock requirements during
   iteration, etc, and alternatives available:
http://www-128.ibm.com/developerworks/java/library/j-jtp07233.html

3) Tutorial on reducing contention:
http://www-128.ibm.com/developerworks/java/library/j-threads2.html
(This has some good links at the end for further info too.)

4) ConcurrentHashMap from java.util.concurrent:
http://www-128.ibm.com/developerworks/java/library/j-jtp08223/index.html


Witness the contradictory strategies (article 3), depending on the actions
needing to be performed, and that the 'library' (eg ST) cannot predict, in
general, the required strategy of the consumer of the library.


HTH
Zen

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