lock statement

  • Thread starter Thread starter Roy Chastain
  • Start date Start date
R

Roy Chastain

Question
If control leaves the locked block does the lock get cleared?

Example (simple and bad coding)
lock(obj)
{
// code
return;
}

It appears to me that the lock does NOT get cleared, which seems a little strange given the 'block' oriented nature of lock.
Since it handles exceptions for you, I had assumed that it handled block exits also.

Can someone confirm or deny my suspicions?

Thanks
 
Hi,

It has to be cleared , what makes you think that it does not?

cheers,
 
I am sorry, your answer is not clear.
By "It has to be cleared", do you mean that I have to clear it manually, or do you mean 'good grief, it must work so that the lock
gets cleared'?

If you mean what makes me think that the compiler generated code does not clear it, then the answer is my code keeps blocking and
it appears that the return did not clear the lock. I changed the method to return after the end of the block and things worked
better.
 
for the lock statement there is no difference wheather the block has exited
normally, with a return or with an exception - the statement uses internally
a finally clause which is executed *always* if the block is left no matter
_how_ the block was left.
 
Roy,

I definitely releases the lock. The lock statement translates into the
following code:

Monitor.Enter(obj)

try
{
// Code in lock block goes here.
}
finally
{
// Release the lock.
Monitor.Exit(obj);
}

The finally clause guarantees that the lock is released when the code
block is exited.

Can you give a short example which shows it is not?
 
Roy Chastain said:
If you mean what makes me think that the compiler generated code does
not clear it, then the answer is my code keeps blocking and it
appears that the return did not clear the lock. I changed the method
to return after the end of the block and things worked better.

I suspect that just means you've got a deadlock which is hard to track
down. The lock always exits the monitor however you leave the block.
 
If it uses a finally clause internally on exit, why is the suggestion
to always add a try/finally clause?

Where did you read that it internally uses a finally clause?

Thanks,
Brett
 
brett said:
If it uses a finally clause internally on exit, why is the suggestion
to always add a try/finally clause?

That recommendation is only if you're using Monitor.Enter/Exit
explicitly. The lock statement is very much like the using statement -
it's a shorthand for try/finally.
Where did you read that it internally uses a finally clause?

The C# language specification. From section 15.12 (ECMA numbering):

<quote>
A lock statement of the form

lock (x) ...

where x is an expression of a reference-type, is precisely equivalent
to

System.Threading.Monitor.Enter(x);
try {
...
}
finally {
System.Threading.Monitor.Exit(x);
}

except that x is only evaluated once.
</quote>
 
guess he didn't know he was dealing with a spec junky...

--
Regards,
Alvin Bruney - ASP.NET MVP

[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
Now available @ www.lulu.com/owc, Amazon.com etc
 
Back
Top