[Mono-dev] Deadlock Detection in Mono Libraries

[Jonathan Pryor]

On Mon, 2010-11-08 at 07:35 +0530, Arun K wrote:
> I am performing a static analysis on the mono 2.4.x libraries.

2.4.x?  How old!  (We're up to 2.8 now...)

> The aim of this analysis is to detect potential deadlock scenarios
> within the libraries. As a first step, I wanted to find if any
> synchronized method invokes another synchronized method either
> directly or eventually

Thus, the *most* important question: How do you define "synchronized"?

My guess is that your definition is a method with the attribute:

        [MethodImpl (MethodImplOptions.Synchronized)]

If this is the case, the problem you're encountering is that this is
explicitly counter to .NET documentation, e.g. [0, 1]:

        Generally, it is best to avoid locking on a public type, or on
        object instances beyond the control of your application. For
        example, lock(this) can be problematic if the instance can be
        accessed publicly, because code beyond your control may lock on
        the object as well. This could create deadlock situations where
        two or more threads wait for the release of the same object.

.NET guidelines advocate declaring a *private* object instance and
locking on that, instead of using Synchronized methods. [2]

In short, if you see [MethodImpl (MethodImplOptions.Synchronized)],
you're either looking at compatibility with .NET, or you're looking at a
probable bug.

 - Jon

[0] http://msdn.microsoft.com/en-us/library/ms173179.aspx
[1] http://msdn.microsoft.com/en-us/library/ms182290(VS.80).aspx
[2] My guess is that the only reason you can lock on System.Object and
not some more restricted type is for Java compatibility...which is the
~same reason that .NET arrays are covariant.