Hello Juval, I'm no expert on this topic, but If you look at the section 11.6.5(Locks and Threads) of the ECMA spec Partition I, you will find the following.
"1. Synchronized Methods ... The CLI shall release the lock when control exits (by any means) the method invocation that first acquired the lock" Also at the section 14.3.3(Implementation Information), it says that "... The lock is released when the method exits, either through a normal return or an exception." So, I think we can consider MethodImplOptions.Synchronized has the same semantics as the C# lock statement has. HTH, Fumiaki Yoshimatsu > -----Original Message----- > From: dotnet discussion [mailto:[EMAIL PROTECTED]] > On Behalf Of Juval Lowy > Sent: Monday, May 27, 2002 9:31 AM > To: [EMAIL PROTECTED] > Subject: [DOTNET] MethodImpl Vs. lock > > > Hi All, > > I was wondering, what is exactly the equivalent code to: > > [MethodImpl(MethodImplOptions.Synchronized)] > public void DoSomething() > { > /* Method code */ > } > > Previous posts to this list have suggested that the equivalent is: > > public void DoSomething() > { > lock(this) > { > /* Method code */ > } > } > > > If you look at the IL, you will see: > > .method public hidebysig instance void DoSomething() cil managed > synchronized > { > } > > So the compiler does not just plant code. > Could it be that the .NET runtime merely locks and unlocks > before and after > the method, without exception handling? > Meaning, is the equivalent code more like: > > public void DoSomething() > { > Monitor.Enter(this); > > /* Method code */ > > Monitor.Exit(this); > } > > > Thanks, > > Juval. > > > [EMAIL PROTECTED] > IDesign Inc. > .NET Design and > Business Solutions > http://www.idesign.net/ You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
