[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [DotGNU]Additional Monitors test cases
From: |
Thong (Tum) Nguyen |
Subject: |
RE: [DotGNU]Additional Monitors test cases |
Date: |
Wed, 5 May 2004 18:05:36 +1200 |
Just wanted to add that this _is_ how pnet monitors is written (bugs not
withstanding) :-).
^Tum
> -----Original Message-----
> From: Thong (Tum) Nguyen [mailto:address@hidden
> Sent: Wednesday, 5 May 2004 6:04 p.m.
> To: 'Russell Stuart'
> Cc: address@hidden
> 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:address@hidden
> > Sent: Wednesday, 5 May 2004 5:35 p.m.
> > To: Thong (Tum) Nguyen
> > Cc: address@hidden
> > 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
> address@hidden
> http://dotgnu.org/mailman/listinfo/developers