https://bugzilla.novell.com/show_bug.cgi?id=662381
https://bugzilla.novell.com/show_bug.cgi?id=662381#c13 Jérémie LAVAL <jeremie.la...@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #13 from Jérémie LAVAL <jeremie.la...@gmail.com> 2011-01-06 13:20:09 UTC --- Again, this is not a problem with the lock itself, merely the fact that it uses Monitor which is re-entrant (see Remarks section on MSDN). In our context, it means that a thread t1 executing a task can also execute another task while still being in the first (when you use a Wait operation, Parallel.For implicitly calls a Wait). Taking you last example, what happens is that a thread t1 executing Foo and taking the lock can during the empty Parallel.For execute one of the Task of the first Parallel.For (the one calling Foo in the first place). Thus you have a recursion (even though the code doesn't exhibit any at first) and when you hit lock for the second time since the thread (and not the task) had taken it already you just go through. I added experimental restrictions to the code to make it less greedy which fix both test cases but I'm waiting to see if it regresses anything else before putting it in a stable release so 2.8.2 won't have it. Meantime my workarounds I described earlier are still applicable. -- 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