[Mono-bugs] [Bug 662381] C# lock () fails on latest Mono runtimes

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=662381

https://bugzilla.novell.com/show_bug.cgi?id=662381#c14


--- Comment #14 from John Costella <john.costella at petermac.org> 2011-01-06 22:23:24 UTC ---
Thanks for working on this, Jérémie.

I don't believe it makes any sense for a nested Parallel.For to be able to
break a lock. In general, if I write

lock (someObject)
{
  Baz();
}

then Baz should not be able to break my lock and allow another thread in.
You're saying that if Baz calls something which calls something else which
happens to have a Task.Wait in it, then my lock can fail. That would break
encapsulation and would mean that locks are unsafe on any Mono runtime that
supports .NET 4, since you don't a priori know whether a method you call might
use TPL and explode your lock.

This is the advice I've just received on MSDN:

--- start quote ---

To me, this seems like a bug in Mono's implementation.

Parallel.For is going to potentially cause the current thread to block (I
believe, internally, using a wait handle's WaitOne call).  

In the Windows implementation, from my understanding, the calling thread will
potentially get used to handle some of the tasks required for the internal
Parallel.For(..) call, which makes complete sense and is a nice optimization. 
This happens because, and only because, the inner loop tasks are children of
the outer task in the task hierarchy (they're created with AttachedToParent
set).  However, the thread running inside Foo (inside the lock) will not get
used by another call to Foo, until the inner Parallel.For completes.  This
would completely prevent multiple instances from entering your lock.

It sounds like Mono's implementation is reusing the main calling thread for
tasks that are not children of the currently executing task.  This is allowing
a second task to entire your lock (since it's the same thread ID), which in
turns causes your behavior.  I, personally, feel that is a bug, and not
appropriate.  From the sound of it, Mono's implementation is ignoring the task
hierarchy entirely.

--- end quote ---

John

-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.