-1

I've got a question about "lock" statement in C#.
MDSN(https://msdn.microsoft.com/en-us/library/c5kehkcz.aspx) says

The lock keyword ensures that one thread does not enter a critical section of code while another thread is in the critical section. If another thread tries to enter a locked code, it will wait, block, until the object is released.

While I feel that, as long as "lock" prevents multiple threads from executing one block of code, then having a "lock" point should be enough. This is like setting a conditional execution point. If .net knows one thread is inside "lock" block, then other threads should wait. This could be fully handled by .net framework itself. But why do we bother to specify an object to lock? This seems redundant to me.

Jota
  • 16,103
  • 7
  • 54
  • 89
vik santata
  • 2,525
  • 5
  • 24
  • 47
  • 3
    If two threads are running on two unrelated instances, you don't want them to be blocked. – SLaks Jun 25 '15 at 02:28
  • Ensuring that all locks, anywhere in the entire application, doing anything, will always suffer contention with all other locks, anywhere in the entire application, doing anything, is a surefire recipe for staggeringly bad concurrency. – Nathan Tuggy Jun 25 '15 at 02:32
  • @SLaks OP is asking why it is necessary to give it an `Object` argument. – Rogue Jun 25 '15 at 02:58
  • See also [What precisely does a “lock” lock?](https://stackoverflow.com/q/21544823), MSDN's [Thread Synchronization](https://msdn.microsoft.com/en-us/library/ms173179.aspx) and [the nearly 3500 other related posts](https://stackoverflow.com/search?q=%5Bc%23%5D+what+does+lock+do%3F) here on Stack Overflow. – Peter Duniho Jun 26 '15 at 06:28

2 Answers2

3

You lock on an object to provide a unique reference for any particular critical code section. Any sort of locking (mutex/semaphores/etc) can be expensive if multiple threads are contending for a specific code section. You don't want a 'universal' lock because then everything that needs to lock will have to contend for the same lock, even if the threads share no common context. You should lock the smallest section of code possible to avoid problems. You should also performance test. Starting four threads that all have a tight loop which locks around a single line (to protect a common context/variable) will perform much worst than non-threaded code.

Dweeberly
  • 4,296
  • 2
  • 19
  • 34
  • This doesn't answer the question that was asked. The OP is asking why, since the lock locks a "critical section" of code, and since the compiler can easily identify that critical section (since it's contained by the `lock` statement's block), is it necessary to provide any identifier at all. Your answer presumes that the OP understands why two or more critical sections should be synchronized with each other, while clearly they do not. – Peter Duniho Jun 26 '15 at 06:32
2

If more than one thread works with a given object, using different code, then you could still have corruption with your proposed 'locked block'.

alexbuzzbee
  • 155
  • 10