lock block with parameter

[Atul Kharecha]

Hi, what is the use of parameter passed in lock block and why it must be always reference type? Thanks.

[PIEBALDconsult]

It's just something to hold onto. Only one thread can hold it at a time, all the others have to wait for it to be passed.

[Atul Kharecha]

Thanks. But you know it is not expected that the parameter should be used inside code, the protected variable can be something else then parameter. So there is no sense in passing parameter like we normally use in methods.

[OriginalGriff]

What I think you are saying is that it makes no sense to use "lock(parameter)" when we could just use "lock". If so, then you are wrong - "lock(parameter)" allows multiple, different locks: "lock(myBuffersSection)" and "lock(myXMLOutputSection)". In this way, only the threads that need to be frozen until a specific lock is available are frozen - all the others can continue.

No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced. This message is made of fully recyclable Zeros and Ones

[Nicholas Butler]

The parameter is a way of identifying a particular synchronization scope. It must be visible to every method that participates in that synchronization. It is usually declared in a class as:

class UsesSynchronization
{
private Object key = new Object();

public SafeMethod()
{
lock( key )
{
...
}
}
}

It must be a reference type because a value type would be boxed in a different object for each call to lock, which is actually syntactic sugar for Monitor.Enter and Monitor.Exit. Nick

---------------------------------- Be excellent to each other :)

[Atul Kharecha]

OK, so can you tell me that when we are sending parameter to the lock block is it treated as an input parameter similar to method? Like we send parameter to the method and method will use it.

[OriginalGriff]

This is going to be a bit complicated, and I strongly recommend you find a book and read up on multithreading, because it is quite important that you understand what (and why) it happens. The lock keyword requires you to specify a token (an object reference) that must be acquired by a thread to enter within the lock scope. When you are attempting to lock down a private instance-level method, you can simply pass in a reference to the current type:

private void SomePrivateMethod()
{
// Use the current object as the thread token.
lock(this)
{
// All code within this scope is thread-safe.
}
}

However, if you are locking down a region of code within a public member, it is safer (and better practice) to declare a private object member variable to serve as the lock token:

public class MyClass
{
// Lock token.
private object threadLock = new object();
public void MyMethod()
{
// Use the lock token.
lock (threadLock)
{
...
}
}
}

Why does it have to be an object? Why can't it be an integer? Or a bool? This is more complex, and it goes back to the beginnings of what you probably learnt when you were starting. Do you remember all that suff about Value types and Reference types? Well, the lock token must be a reference type, because otherwise when you pass it to the lock block, it would get re-packaged into a reference type container, which would then be locked. If a second thread came along and passed it to a lock block again, it gets re-packaged again, and a different reference type container gets locked. Remember that (like so many things in C#) "lock(token)" is a "short cut" for a method call - in this case Monitor.Enter and Monitor.Exit - so you are actually passing the token to a method. The parameter works teh same as it would for any other method, packaging and all. Does this make sense? It is a bit complicated!

No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced. This message is made of fully recyclable Zeros and Ones