1
object c = new object();
lock(c)
{
}

Why should i pass object to lock keyword while synchronizing above code.If i pass also where will it be used.I know it is used for acquiring a lock on that object.but i wanted to know how can we acquire lock on object in depth.How does the thread release the lock on the object we pass in lock keyword.

Matías Fidemraizer
  • 63,804
  • 18
  • 124
  • 206
Akash
  • 71
  • 5
  • 1
    http://blog.coverity.com/2014/02/12/how-does-locking-work/#.ViuG5Wbos6Y – Steve Oct 24 '15 at 13:28
  • There are like five questions in here; try to ask *one specific question* per question posted; you're more likely to get a good answer. – Eric Lippert Oct 24 '15 at 14:34

2 Answers2

4

lock statement is a syntactic sugar of using Monitor approach to thread synchronization. Monitor represents an exclusive lock on some resource, and in .NET a resource is an object.

Why you need to give an object reference to a Monitor? Well, because you want to synchronize the access to the whole object in a multi-threaded environment.

How does the thread release the lock on the object we pass in lock keyword?

Think about lock as follows:

Monitor.Enter(obj);

try
{
    // This would be the code inside the "lock" block
}
finally
{
    if(Monitor.IsEntered(obj))
       Monitor.Exit(obj); // <-- This is how a Monitor releases the lock
}
Matías Fidemraizer
  • 63,804
  • 18
  • 124
  • 206
0

you don't need to restrict your locking to an Object object, you could lock a Dictionary object for example, to prevent other threads from adding or deleting from the collection.

or

if you don't want to use the lock keyword, you could use [MethodImpl(MethodImplOptions.Synchronized)]

eg.

 [MethodImpl(MethodImplOptions.Synchronized)]
 static void mySynchronisedTask()
 {
     //do things that i want to be synchronised
     Console.WriteLine("before sync task");
     Thread.Sleep(5000);
     Console.WriteLine("after sync task");
 }
Sean Bradley
  • 3,254
  • 1
  • 17
  • 10
  • 2
    First off, a dictionary is an object. Second, though this is possible, it's actually a bad idea if the dictionary is public. By locking on something that the public can access, that means that code you don't control could be taking the lock. That in turn can cause performance problems due to contention or correctness problems due to deadlock. It also means that you have the flexibility to change your locking policy in the future. The safest thing to do is to only lock on private objects that are purpose-built to be locks. – Eric Lippert Oct 24 '15 at 14:33
  • 1
    I forgot to mention also that the CLR implementation is optimized for the only-used-as-a-lock-object scenario. – Eric Lippert Oct 24 '15 at 14:37
  • @EricLippert Any place we can read about that optimization? – Yuval Itzchakov Oct 24 '15 at 16:53
  • 1
    @YuvalItzchakov http://stackoverflow.com/questions/1803298/what-is-a-sync-block-and-tips-for-reducing-the-count a sync block can have multiple uses. the clr assumes that any given object is unlikely to need a sync block for two things. – Eric Lippert Oct 25 '15 at 01:43
  • I dont want to pass any object.i want to synchronize without passing the object.Why is the object required to synchronize.In java we directly synchronize using "synchronize".we wont pass object there i guess – Akash Oct 25 '15 at 06:12
  • The c# equivalent of the java synchronised keyword is [MethodImpl(MethodImplOptions.Synchronized)] – Sean Bradley Oct 25 '15 at 07:49
  • @Akash: The Java style synchronization is a very bad idea for the reasons which I outlined in a comment above. You do not say *why* you want to do this dangerous thing; why do you want to do something the dangerous and inflexible way when there is a cheap, easy, standard solution that is both safer and gives you more options for improving the code in the future? – Eric Lippert Oct 25 '15 at 15:29