Knut Anders Hatlen wrote:
Hi,
I think I once read that the engine code in some cases uses
synchronized containers because the code was written before the
unsynchronized containers were added to the JDK, and not because
synchronization was needed. Is that correct?
Yes. As you point out replacing them with unsynchronized Java 2
collections does require investigation as to the possible code paths
into the object.
In RAMTransaction, there is no explicit synchronization, but it
contains four Vectors and one Hashtable. Is it safe to assume that
RAMTransaction's methods are called from a single thread only and that
Vector/Hashtable could be replaced with ArrayList/HashMap?
I think you are correct on this.
In GenericLanguageConnectionContext, there are two for-loops which
iterate over the activations Vector and have this comment:
/* For every activation */
// synchronize on acts as other threads may be closing activations
// in this list, thus invalidating the Enumeration
However, I don't see how the code that follows this comment is safe if
another thread is modifying the Vector concurrently. For instance,
there is nothing that prevents another thread from removing an element
from the vector between the index calculation and the actual access to
the vector. This made me wonder whether the synchronization was needed
in the first place. Isn't it so that a thread will attempt to
synchronize on the connection object before it accesses the language
connection context? Or are there other ways to access the lcc?
That comment *may* be from the time activations were closed in
finalization (which lead to deadlocks). Since activations are now just
marked as inactive by finalization it most likely true that the Vector
could be replaced by an ArrayList.
Dan.
