[Mono-dev] Deadlock Detection in Mono Libraries

[Arun K]

Hi Pryor,

Thanks for the info and the reference.
The version of mono I used is 2.4.2.3 build 2008, but since our analysis is
at a preliminary stage, the version is of not much concern.

At the moment we only look at methods that are decorated with the
MethodImplOptions.
Synchronized attribute. Going further we would be looking at the
'lock(object)' constructs as well in our analysis. I will update you on my
future findings.
Thanks you once again.

-Arun


On Mon, Nov 8, 2010 at 8:03 PM, Jonathan Pryor <jonpryor at vt.edu> wrote:

> 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<http://msdn.microsoft.com/en-us/library/ms182290%28VS.80%29.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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20101109/ba99d75f/attachment.html