Question

I read about lock, though not understood nothing at all.
My question is why do we use a un-used object and lock that and how this makes something thread-safe or how this helps in multi-threading ? Isn’t there other way to make thread-safe code.

public class test {
    private object Lock { get; set; }

    ...
    lock (this.Lock) { ... }
    ...
}

Sorry is my question is very stupid, but i don’t understand, although i’ve used it many times.

Answer 1

Accessing a piece of data from one thread while other thread is modifying it is called “data race condition” (or just “data race”) and can lead to corruption of data. (*)

Locks are simply a mechanism for avoiding data races. If two (or more) concurrent threads lock the same lock object, then they are no longer concurrent and can no longer cause data races, for the duration of the lock. Essentially, we are serializing the access to shared data.

The trick is to keep your locks as “wide” as you must to avoid data races, yet as “narrow” as you can to gain performance through concurrent execution. This is a fine balance that can easily go out of whack in either direction, which is why multi-threaded programming is hard.

Some guidelines:

• As long all threads are just reading the data and none will ever modify it, lock is unnecessary.
• Conversely, if at least one thread might at some point modify the data, then all concurrent code paths accessing that same data must be properly serialized through locks, even those that only read the data.
  • Using a lock in one code path but not the other will leave the data wide open to race conditions.
  • Also, using one lock object in one code path, but a different lock object in another (concurrent) code path does not serialize these code paths and leaves you wide open to data races.
  • On the other hand, if two concurrent code paths access different data, they can use different lock objects. But, whenever there is more than one lock object, watch out for deadlocks. A deadlock is often also a “code race condition” (and a heisenbug, see below).
• The lock object does not need to be (and usually isn’t) the same thing as the data you are trying to protect. Unfortunately, there is no language facility that lets you “declare” which data is protected by which lock object, so you’ll have to very carefully document your “locking convention” both for other people that might maintain your code, and for yourself (since even after a short time you will forget some of the nooks and crannies of your locking convention).
• It’s usually a good idea to protect the lock object from the outside world as much as you can. After all, you are using it for the very sensitive task of locking and you don’t want it locked by external actors in unforeseen ways. That’s why using this or a public field as a lock object is usually a bad idea.
• The lock keyword is simply a more convenient syntax for Monitor.Enter and Monitor.Exit.
• The lock object can be any object in .NET, but value objects will be boxed in the call to Monitor.Enter, which means threads will not share the same lock object, leaving the data unprotected. Therefore, only use reference types as lock objects.
• For inter-process communication you can use a global mutex, which can be created by passing a non-empty name to Mutex Constructor. Global mutexes provide essentially the same functionality as regular “local” locking, except they can be shared between separate processes.
• There are synchronization mechanisms other than locks, such as semaphores, condition variables, message queues or atomic operations. Be careful when mixing different synchronization mechanisms.
• Locks also behave as memory barriers, which is increasingly important on modern multi-core, multi-cache CPUs. This is part of the reason why you need locks on reading the data and not just writing.

(*) It is called “race” because concurrent threads are “racing” towards performing an operation on the shared data and whoever wins that race determines the outcome of the operation. So the outcome depends on timing of the execution, which is essentially random on modern preemptive multitasking OSes. Worse yet, timing is easily modified by a simple act of observing the program execution through tools such as debugger, which makes them “heisenbugs” (i.e. the phenomenon being observed is changed by the mere act of observation).