This recipe illustrates another common multithreaded error called a deadlock. Since a deadlock will cause a program to stop working, the first piece in this example is a new Monitor construct that allows us to avoid a deadlock. Then, the previously described lock keyword is used to get a deadlock.
To work through this recipe, you will need Visual Studio 2015. There are no other prerequisites. The source code for this recipe can be found at BookSamples\Chapter1\Recipe10.
To understand the multithreaded error deadlock, perform the following steps:
Start Visual Studio 2015. Create a new C# console application project.
In the
Program.csfile, add the followingusingdirectives:using System; using System.Threading; using static System.Console; using static System.Threading.Thread;
Add the following code snippet below the
Mainmethod:static void LockTooMuch(object lock1, object lock2) { lock (lock1) { Sleep(1000); lock (lock2); } }Add the following code snippet inside the
Mainmethod:object lock1 = new object(); object lock2 = new object(); new Thread(() => LockTooMuch(lock1, lock2)).Start(); lock (lock2) { Thread.Sleep(1000); WriteLine("Monitor.TryEnter allows not to get stuck, returning false after a specified timeout is elapsed"); if (Monitor.TryEnter(lock1, TimeSpan.FromSeconds(5))) { WriteLine("Acquired a protected resource succesfully"); } else { WriteLine("Timeout acquiring a resource!"); } } new Thread(() => LockTooMuch(lock1, lock2)).Start(); WriteLine("----------------------------------"); lock (lock2) { WriteLine("This will be a deadlock!"); Sleep(1000); lock (lock1) { WriteLine("Acquired a protected resource succesfully"); } }Run the program.
Let's start with the LockTooMuch method. In this method, we just lock the first object, wait for a second, and then lock the second object. Then, we start this method in another thread and try to lock the second object and then the first object from the main thread.
If we use the lock keyword like in the second part of this demo, there will be a deadlock. The first thread holds a lock on the lock1 object and waits while the lock2 object gets free; the main thread holds a lock on the lock2 object and waits for the lock1 object to become free, which will never happen in this situation.
Actually, the lock keyword is syntactic sugar for the Monitor class usage. If we were to disassemble code with lock, we would see that it turns into the following code snippet:
bool acquiredLock = false;
try
{
Monitor.Enter(lockObject, ref acquiredLock);
// Code that accesses resources that are protected by the lock.
}
finally
{
if (acquiredLock)
{
Monitor.Exit(lockObject);
}
}Therefore, we can use the Monitor class directly; it has the TryEnter method, which accepts a timeout parameter and returns false if this timeout parameter expires before we can acquire the resource protected by lock.