[Mono-bugs] [Bug 317647] Thread.Interrupt not working

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=317647#c2





--- Comment #2 from Paolo Molaro <lupus at novell.com>  2007-10-29 08:49:16 MST ---
Here are a few findings on this issue:
the number of iterations of the T2 loop are mostly random, you may get just one
or many (and likely forever). This explains the fact that someone can replicate
and others not. Looking at the code, it is clear that the T2 loop has a small
window outside the lock where, if it's preempted by the kernel and control is
passed to T1, the lock is taken by T1 and the program finishes. Adding a small
Sleep in the loop outside of the lock makes this explicit and the program
always terminates after a single loop.
This seems to suggest that the MS runtime (and/or the windows kernel
implementation of the locks) tends to prefer other threads than the one
releasing a Monitor. Doing something similar in our implementation has the same
effect of adding the small sleep to the program. My change in monitor.c looks
like:
@@ -605,6 +617,7 @@
                 */
                if (mon->entry_count > 0) {
                        ReleaseSemaphore (mon->entry_sem, 1, NULL);
+                       sched_yield ();
                }
        } else {
                LOCK_DEBUG (g_message (G_GNUC_PRETTY_FUNCTION
(this is inside mono_monitor_exit ()).
I could easily reproduce the mostly infinite T2 loop by just reducing all the
sleep times in the program to one tenth and setting the MONO_NO_SMP=1 env var.

We need someone to confirm that with the MS runtime the T2 loop indeed happens
just once (by running the program at least 10 times, reducing all the sleep
times to one tenth). The same testing should be also done on a uniproc box or
by pinning the process to just one cpu.

Note that I added the yield only in the contended case, so the performance
regression of causing lock fairness shouldn't be large.


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