To see the problem, run the following program:

===
class Foo {
    static Foo instance = null;

    public static Foo get_instance() {
        lock (instance) {
            if (instance == null)
                instance = new Foo();
        }
        return instance;
    }
}

int thread_func() {
    stdout.puts("thread started\n");
    Foo.get_instance();
    stdout.puts("thread exiting\n");
    return 0;
}

void main() {
    try {
        for (int i = 0; i < 5 ; ++i)
            Thread.create<int>(thread_func, false);
    } catch (ThreadError e) {
        error(e.message);
    }
    Thread.usleep(10000000);
}
===

On my 4-core machine (running Vala 0.15.2 and Ubuntu 12.04), the program's output typically looks like this:

===
thread started
thread started
thread started
thread started
thread started
thread exiting
===

One or more threads successfully complete execution, but one or more threads remain deadlocked in the lock statement, unexpectedly.

I *believe* that what's happening is that Vala is calling g_static_rec_mutex_init to initialize the lock only after some threads are already waiting in the lock() statement.  Then those threads remain deadlocked, I think.

(By the way, this problem recently caused a subtle hang in Shotwell, which was using the design pattern above to initialize certain singleton objects.)