Deadlock Visual Studio, bug?

First of all, we must admit that this title has a few title parties, but this is not a complete title party. Using the "correct" debugging method can indeed cause a deadlock for. As for vs deadlock, it is not a bug. This issue remains to be discussed. I don't want to talk about it. First, let's see how to use the "correct" method to deadlock.

Create a console project and copy the following code:

using System.Threading;namespace DeadlockVS{    class Program    {        static object _obj = new object();        static void Main(string[] args)        {            Thread.CurrentThread.Name = "Main Thread";            ThreadStart ts = () =>            {                while (true)                {                    lock (_obj)                        Thread.Sleep(100);                    Thread.Sleep(1);                }            };            for (int i = 0; i < 2; i++)                new Thread(ts).Start();            Thread.Sleep(1000);            ts();        }        static int Get()        {            lock (_obj)                return 1;        }    }}

Then insert the correct breakpoint in the correct position:

 

Enter get () in the real-time window ()

 

Now your vs has a 99.99% probability of reaching a "deadlock" State (if there is no deadlock, congratulations, you can buy a two-color ball now, remember to score a point ). IDE is waiting for the host process to return results, and the host process needs to wait for one of the threads to release the lock. Because the host process is in the debugging status, the host process cannot continue to execute the next code and cannot release the lock, eventually, a deadlock exists. Although it is a deadlock, the vs UI is not locked, so the only thing we can do now is to end debugging.

 

Now that the experiment is over, let's discuss whether this is a bug in?

Fang viewpoint:

• It will affect normal debugging. Of course, it is a bug.
• If the program ends abnormally, it is regarded as a bug.

Opposing point of view:

• The debugging method is incorrect.
• The bug itself is an error. It is not implemented according to the normal understanding, not to say that a deadlock is a bug.

How can we solve this "bug "?

• From the programmer's point of view, you can only increase your coding and debugging capabilities.
• From the perspective of vs robustness, you can use the sandbox mode to actively exit after a certain period of time has not been obtained.

Let's take a look at how Wikipedia defines bugs: program errors (English: Bugs), terms in programming, it refers to abnormal functions, crashes, data loss, and abnormal interruptions caused by program errors during software operation. Http://zh.wikipedia.org/wiki/%E7%A8%8B%E5%BA%8F%E9%94%99%E8%AF%AF

 

Another blog article titled A serious bug in WPF and SL that can cause any host Program to crash.