lock potential hazards

As a follow-up to my previous post about the Singleton design pattern potential hazard, I think it is useful to point out another potential hazard in multithreading scenarios.

Some solutions for the implementation of the Singleton design pattern are using a construct such as the following:

lock (typeof(MyType))
{
  ...
}

This is not a good idea as it can cause problems, as the .NET Framework SDK documentation explains:

In multithreading scenarios, do not lock Type objects in order to synchronize access to static (Shared in Visual Basic) data. Other code, over which you have no control, might also lock your class type. This might result in a deadlock. Intead, synchronize access to static data by locking a private static (Shared in Visual Basic) object.

The bad news is that this is the help for the Type class, and not for the lock keyword. The help for the lock keyword (here and there) does not talk about this.