[Mono-dev] Deadlock Detection in Mono Libraries
jonpryor at vt.edu
Mon Nov 8 09:33:12 EST 2010
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:
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. 
In short, if you see [MethodImpl (MethodImplOptions.Synchronized)],
you're either looking at compatibility with .NET, or you're looking at a
 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.
More information about the Mono-devel-list