The lock construct does what you want it to do. The object who's lock is being acquired is the key; not the code that's acquiring the lock. So any piece of code anywhere that agrees to wait for exclusive ownership of a given lock will be blocked if another piece of code currently holds that same lock. In your case, both pieces of code have agreed to rendezvous on the same lock (this), so you'll get the behavior you want.
-Mike http://staff.develop.com/woodring http://www.develop.com/devresources ----- Original Message ----- From: "Keith Hill" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, April 11, 2002 11:04 AM Subject: [DOTNET] C# Lock question > If you have two (or more) sections of "locked" code within different > instance methods of an object and you always lock on "this", are you > guaranteed that only one of the locked sections of code will be running at > time for that object instance - no matter how many threads are trying to > call the locked code? > > I basically to ensure this type of behavior: > > public void Meth1() > { > lock(this) { > .. do some work ... > m_thread = null; > } > } > > public void Meth2() > { > lock(this) { > if (m_thread != null) m_thread.Abort(); > } > } > > My basic worry is that between the test on m_thread != null and calling > m_thread.Abort(), another thread will call Meth1 and I would be hosed > unless the lock statements work as I hope they do. > > -- > Keith > > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
