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

Adam Clauss <(E-Mail Removed)> wrote:
> 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 - <(E-Mail Removed)>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

"Jon Skeet [C# MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>> 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

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