Deadlock in DateTimeZone/FixedDateTimeZone static initialization

[david-at-aws]

We've got a user reporting a deadlock while using the AWS SDK for Java. The user is calling into two different parts of the SDK from two different threads. One ends up accessing DateTimeZone.UTC while the other ends up directly creating a new FixedDateTimeZone.

Thread 1 grabs a lock on DateTimeZone to run its static initialization block. Thread 2 grabs a lock on FixedDateTimeZone to run its static initialization block. FixedDateTimeZone extends DateTimeZone, so the first thing Thread 2 does is try to grab a lock on DateTimeZone to see if it has been initialized yet. Meanwhile, Thread 1 attempts to grab a lock on FixedDateTimeZone to see if it has been initialized yet because the static initializer creates an instance of FixedDateTimeZone to assign to DateTimeZone.UTC. Boom, deadlock.

Minimal repro code:

import org.joda.time.DateTimeZone;
import org.joda.time.tz.FixedDateTimeZone;

public class Test {
    public static void main(String[] args) {
        Thread one = new Thread() {
            @Override
            public void run() {
                DateTimeZone zone = DateTimeZone.UTC;
            }
        };

        Thread two = new Thread() {
            @Override
            public void run() {
                new FixedDateTimeZone("GMT", "GMT", 0, 0);
            }
        };

        one.start();
        two.start();
    }
}

deadlocks pretty reliably for me with:

"Thread-1" prio=10 tid=0x0a01a800 nid=0xbfb in Object.wait() [0x6db8d000]
   java.lang.Thread.State: RUNNABLE
        at Test$2.run(Test.java:16)

"Thread-0" prio=10 tid=0x0a019000 nid=0xbfa in Object.wait() [0x6dbde000]
   java.lang.Thread.State: RUNNABLE
        at org.joda.time.DateTimeZone.<clinit>(DateTimeZone.java:95)
        at Test$1.run(Test.java:9)

Is this something that other people have run into? I can certainly work around it by adding no-op references to DateTimeZone before creating any FixedDateTimeZone instances, but that seems awfully fragile (and in particular doesn't protect against something else in my users' processes directly referencing FixedDateTimeZone and locking in the other direction). Any other recommendations? Unfortunately, there doesn't seem to be a straightforward way of fixing this in JodaTime without breaking DateTimeZone.UTC...

[jodastephen]

Please verify the change works for you. AFAICT, it is backwards compatible, but if you think it isn't please let me know.

[david-at-aws]

Thanks Stephen! As expected, I can no longer reproduce the deadlock after the change. We don't depend on DateTimeZone.UTC being a FixedDateTimeZone (or equal to other FixedDateTimeZones with the same id and offsets), so no problem there either at least for us.