Xalan-J 1.2 deadlock

[steven serocki <sm...@metreo.com>]

There is a race that can result in circular deadlock where two threads
try to lookup the same Locale in the same hashtable, and the tardier thread
is holding the lock associated with the Locale object. The lock for the
Locale reference is needed for the synchronized method Locale.getHash().

1: Thread 1: in ElemNumber.getNumberFormatter, Thread 1 locks the lock
associated with Locale.getDefaultLocale() via a synchronized statement.


2: Thread 2 enters the NumberFormat.getNumberInstance path via
XRTreeFrag.num. To do DecimalFormatSymbols constructor business, Thread 2 is
interested in looking up Locale.defaultLocale in
DecimalFormatSymbols.cachedLocaleData Hashtable. Thread 2 successfully locks
the lock associated with the Hashtable, but blocks for the defaultLocale
lock in the synchronized method Locale.hashCode().

3: Thread 1 plods onwards on the NumberFormat.getNumberInstance path via
ElemNumber.getNumberFormatter. Thread 1 blocks for the lock associated with
the DecimalFormatSymbols.cachedLocaleData Hashtable lock held by Thread 2,
who is waiting on the lock for the default locale held by us...



I believe a safer alternative to

synchronized(possiblySharedLocale) {
SomeMethodUltimatelyCallingIntoJavaRuntime(possiblySharedLocale)
}

Would be the moral equivalent of

Locale allmineminemine = (Locale) possiblySharedLocale().clone();
UsefulResult = SomeMethodUltimatelyCallingIntoJavaRuntime(allmineminemine );

-ss