Behavior of Monitor.Wait and exception

[Adam Clauss]

Documentation states that a call to Wait releases the lock, and will not
return until the lock is reacquired.

How do exceptions figure into this? Are they considered a form of "return"?

Example:

lock (someObj)
{
try
{
Monitor.Wait(someObj);
}
catch (Exception ex)
{
//What is the state of the lock here?
}
}

Will the lock ALWAYS be re-acquired even for exceptions (such as
ThreadInterruptedException)?

Thanks!
--
Adam Clauss

[Jon Skeet [C# MVP]]

Adam Clauss <ca*****@tamu.eduwrote:

Documentation states that a call to Wait releases the lock, and will not
return until the lock is reacquired.

How do exceptions figure into this? Are they considered a form of "return"?

Example:

lock (someObj)
{
try
{
Monitor.Wait(someObj);
}
catch (Exception ex)
{
//What is the state of the lock here?
}
}

Will the lock ALWAYS be re-acquired even for exceptions (such as
ThreadInterruptedException)?

In 1.0/1.1, there's a bug where in certain situations the lock isn't
reacquire. In 2.0 this appears to be fixed. I'm not entirely sure what
the behaviour is though - it could lead to deadlock even if the thread
is being aborted, which doesn't sound great.

See http://www.yoda.arachsys.com/csharp/threads/abort.shtml for a
complete example showing the broken behaviour on 1.1 (it works on 2.0).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Adam Clauss]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

>Will the lock ALWAYS be re-acquired even for exceptions (such as
ThreadInterruptedException)?

In 1.0/1.1, there's a bug where in certain situations the lock isn't
reacquire. In 2.0 this appears to be fixed. I'm not entirely sure what
the behaviour is though - it could lead to deadlock even if the thread
is being aborted, which doesn't sound great.

See http://www.yoda.arachsys.com/csharp/threads/abort.shtml for a
complete example showing the broken behaviour on 1.1 (it works on 2.0).

Interesting writeup... I wasn't aware of that bug. Although I cannot say I
have ever actually used Interrupt or Abort. I'm not using them in my
current situation either, but rather attempting to account for the
possibility that someone else may use them.

I am in .NET 2.0, so for now, I am going to go for the hope that it DOES
reacquire the lock (I do not see any method to "check to see" if the current
thread owns a lock?)

--
Adam Clauss

[Jon Skeet [C# MVP]]

Adam Clauss wrote:

See http://www.yoda.arachsys.com/csharp/threads/abort.shtml for a
complete example showing the broken behaviour on 1.1 (it works on 2.0).

Interesting writeup... I wasn't aware of that bug. Although I cannot say I
have ever actually used Interrupt or Abort. I'm not using them in my
current situation either, but rather attempting to account for the
possibility that someone else may use them.

I am in .NET 2.0, so for now, I am going to go for the hope that it DOES
reacquire the lock (I do not see any method to "check to see" if the current
thread owns a lock?)

By the looks of it, it does reacquire the lock - I don't know what
happens if another thread has got it and never releases it though. And
no, I don't know of any way of testing whether or not you hold a lock
without any potential side-effects. (Pulsing the lock or waiting on it
will throw an exception if you don't hold the lock, but they could have
side-effects if you do.)

Jon