RE: Additional Monitors test cases

Just wanted to add that this _is_ how pnet monitors is written (bugs not
withstanding) :-).

^Tum

> -----Original Message-----
> From: Thong (Tum) Nguyen [mailto:tum-x2aT3/[email protected]]
> Sent: Wednesday, 5 May 2004 6:04 p.m.
> To: 'Russell Stuart'
> Cc: [email protected]
> Subject: RE: [DotGNU]Additional Monitors test cases
> 
> I agree.  I was wrong in that statement.  The thread in threadFunc doesn't
> wake up until the first thread releases its lock (or in this case, when it
> calls Abort).  The weird thing is that after the abort, both threads are
> in
> a lock block though only one owns the lock.
> 
> > -----Original Message-----
> > From: Russell Stuart [mailto:[email protected]]
> > Sent: Wednesday, 5 May 2004 5:35 p.m.
> > To: Thong (Tum) Nguyen
> > Cc: [email protected]
> > Subject: RE: [DotGNU]Additional Monitors test cases
> >
> > On Wed, 2004-05-05 at 14:26, Thong (Tum) Nguyen wrote:
> > > I haven't had a chance to run your tests but the last two look highly
> > time
> > > dependent.  For example:
> > >
> > >                public String testMonitorAbortAfterWait()
> > >                {
> > >                        ...
> > >                        lock (this.o)
> > >                        {
> > >                                Monitor.Pulse(o);
> > >                                Thread.Sleep(2*1000);
> > >                                thread.Abort();
> > >                                this.seen = true;
> > >                        }
> > > 				...
> > >                }
> > >
> > >                void threadFunc()
> > >                {
> > >                        Monitor.Enter(this.o);
> > >                        lock (this)
> > >                        {
> > >                                Monitor.Pulse(this);
> > >                        }
> > >                         try
> > >                         {
> > >                                 Monitor.Wait(this.o);
> > >                                 this.result = "Expected
> > > System.Threading.ThreadAbortExcep
> > >                                 return;
> > >                         }
> > >                         catch (ThreadAbortException)
> > >                         {
> > >                          ...
> > > 				}
> > >
> > > The first thread pulses "o" which causes the thread inside threadFunc
> to
> > > wakeup.  Once it wakes up, it immediately returns with "Expected
> > > ThreadAbortException".  The first thread doesn't even get a chance to
> > abort
> > > the thread.
> >
> > Ahh, I see where the problem lies.  This is not documented at all well
> > by Microsoft.  Fortunately, the C# Monitors are meant to be a fairly
> > exact emulation of the java monitors, and thus you can rely on the Java
> > doco for this case.   That is why I sent you a java URL - so you could
> > read and understand what I was on about.  Here is the URL again:
> > http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#wait(long)
> >
> > You may not be convinced that C# monitors are meant to be an exact
> > emulation of the Java ones.  I offer three arguments re why I think they
> > are:
> >
> > 1.  It would be very yucky if they behaved in any other manner.  When
> >     programmer writes:
> >       lock (obj) { ... @1 ...; wait(obj); ... @2 ... }
> >     He justifiably expects the code at both @1 and @2 to be guarded
> >     by the lock.  If that were no so, every Java / C# book in existence
> >     would say the above is bad style.  They would instead say that since
> >     there are no firm guarantees that the lock is in place when @2 is
> >     executed, you should instead write this:
> >       lock (obj) { ... @1 ...; wait(obj); } ... @2 ...
> >
> > 2.  I have a book titled "C# for the Java programmer", ISBN 0735617791.
> >     It says that are the same.
> >
> > 3.  Look at this URL.
> >       http://www.di.unipi.it/~boerger/Papers/CSharp/CsharpThread.pdf
> >     It is a excellent reference on C# threads.  I read with some
> >     amusement in the introduction:
> >       "A program developer has to rely solely on the class library
> >       documentation that comes with Microsoft s .NET framework Software
> >       Development Kit [11]. Unfortunately, that documentation is not
> >       very precise with respect to threads, locks and memory issues.
> >       ... For example, specifications of Thread.Interrupt,
> >       Thread.Suspend and Thread.Resume are not included in [5]."
> >       :
> >       [5] Common Language Infrastructure (CLI). Standard ECMA 335, 2001.
> >     Oh joy .. that does make life hard, doesn't it.  Anyway, near the
> >     top of page 17 this comment appears:
> >       "Injecting a ThreadAbortException or a ThreadInterruptedException
> >       into a thread means to create a new excpetion object and to force
> >       the thread to throw the exception (using Fail). If the thread is
> >       Syncing, Sleeping or Joined, its execution state is changed to
> >       Active in order that the exception can propagate upwards and
> >       probably terminate the thread. If the thread is Waiting, it is
> >       moved to the readyQueue and has to re-acquire the lock, since in
> >       this case the thread is still in a critical section of code and
> >       possible exception handlers and finally blocks should only be
> >       executed under the exclusive control of the monitor. If the thread
> >       is Pulsed, its execution state is not updated, since the thread
> >       has to re-acquire the lock before propagating the exception."
> >     You could do a lot worse than use this document as the spec for
> >     the PNet C# thread code.
> >
> > Have I convinced you?
> >
> > PS, I posted this to the developers list, as I think this discussion is
> > important.
> >
> 
> 
> _______________________________________________
> Developers mailing list
> [email protected]
> http://dotgnu.org/mailman/listinfo/developers