https://bugzilla.novell.com/show_bug.cgi?id=662381
https://bugzilla.novell.com/show_bug.cgi?id=662381#c5 --- Comment #5 from John Costella <john.coste...@petermac.org> 2011-01-05 23:58:35 UTC --- Hi Jérémie, I don't think you grasp the bug. Let me simplify it in pseudocode. We have something like: static Main() { Parallel.For( ... Foo() ); } static Foo() { lock (locker) { Bar(); } } static object locker; static Bar() { Parallel.For( ... nothing that calls Foo() directly or indirectly ); } OK, let's say Main's Parallel.For() spawns two threads A and B. They both call Foo(). Let's say A gets there first, and gets the lock. B blocks at the lock. Then, inside the lock, A calls Bar(). Inside Bar(), A finds a Parallel.For() that does something irrelevant, unrelated to the above code. Regardless of whether or not this spawns more threads or just runs on thread A, it should complete and Bar() return thread A to Foo() before thread A releases the lock and thread B is unblocked. What is happening is that when thread A gets to the Parallel.For() in Bar(), sometimes thread B is immediately unblocked, and starts wandering through the critical section of code in Foo() while thread A still holds the lock to it. That simply shouldn't happen. I don't know whether it's TPL or the threading libraries themselves that possess the bug, but it's a bug. Thanks 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. _______________________________________________ mono-bugs maillist - mono-bugs@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-bugs
