[Mono-bugs] [Bug 49824][Nor] Changed - Threading.SyncronizationException thrown on calling Monitor.Exit on an object that has not been locked.

[bugzilla-daemon@bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by dick@ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=49824

--- shadow/49824	2003-10-18 09:57:06.000000000 -0400
+++ shadow/49824.tmp.27503	2003-10-20 11:12:35.000000000 -0400
@@ -2,13 +2,13 @@
 Product: Mono/Runtime
 Version: unspecified
 OS: Red Hat 9.0
 OS Details: Standard Install
 Status: NEW   
 Resolution: 
-Severity: 
+Severity: Unknown
 Priority: Normal
 Component: misc
 AssignedTo: mono-bugs@ximian.com                            
 ReportedBy: gileslforster@yahoo.co.uk               
 QAContact: mono-bugs@ximian.com
 TargetMilestone: ---
@@ -84,6 +84,50 @@
 leading to incompatible code. Not sure what the ECMA standard says but 
 don't know where to look.
 
 Thanks,
 
 Giles
+
+------- Additional Comments From dick@ximian.com  2003-10-20 11:12 -------
+Looks like the ms Monitor implementation is rather buggy.
+
+using System;
+using System.Threading;
+
+namespace ConsoleApplication
+{
+        class Class1
+        {
+                static Class1 x;
+
+                static void OtherThread()
+                {
+                        Monitor.Exit(x);
+                        Console.WriteLine("Passed x Exit");
+                }
+
+                [STAThread]
+                static void Main(string[] args)
+                {
+                        x = new Class1();
+                        Monitor.Enter(x);
+                        Thread thr=new Thread(new
+ThreadStart(Class1.OtherThread));
+                        thr.Start();
+                        thr.Join();
+
+                        Console.WriteLine("All done.");
+                }
+        }
+}
+
+prints both WriteLines for me, ms runtime 1.1.
+
+Reading the Monitor class documentation again, I suppose it could be
+argued that "The current thread does not own the lock for the
+specified object" could be read so as to not throw
+SynchronizationLockException when the object is not locked at all, but
+unless my test above is faulty, it isn't thrown even when another
+thread _does_ own the lock.  (Changing the Monitor.Exit(x) into a
+Monitor.Enter(x) does deadlock as expected though.)
+