On 14 Nov 2008, at 19:12, [EMAIL PROTECTED] wrote:

<snip />

... there seems to be another problem: changeLock is not
a 'final' variable, nor is it declared 'volatile'.
As a consequence:
a) since it is neither final nor volatile, it is not guaranteed to be properly initialized (some threads may see 'null' instead of the Object instance) b) since it is not final, it is theoretically possible to re-assign the changeLock member to a different instance, which would lead to unpredictable behavior. It is possible for two threads to enter the synchronized block, since
they have each locked a separate instance.

Looking closer at the code, changeLock is only re-assigned in case of a call to the private FontCache.readObject() method. Since this method does not seem to be used, maybe making the member final would make sense...

OTOH, I'm not the creator of this class, hence why I'm asking first:
Does anyone see a potential problem with the proposed change?
* removal of the unused readObject()
* changing the changeLock member to become final
* the small change proposed by the reporter

This should resolve any multi-threading weirdness, IIC.

WDYT? Anyone?


Reply via email to