C #4.0 "fixed" deadlock

A few years ago, Eric lippert noticed thatSource codeOptimization building and non-optimization building may lead to different potential deadlocks. This issue will be "fixed" in C #4.0 ". The fix is enclosed in quotation marks because the solution also has its own problems.

The initial problem may be that the compiler is converting il into a machine.CodeWhen you enable or disable the optimizer and debugger, you can insert the no-op command in an inconsistent way. Lippert said:

Recall that lock (OBJ) {body} is actually the syntax of the following code:
VaR temp = OBJ;
Monitor. Enter (temp );
Try {body}
Finally {monitor. Exit (temp );}

The problem here is that if the compiler is in Monitor. the no-op command is generated between enter and the region protected by try, so it is possible to run in Monitor. A thread termination exception is thrown after enter and before try. Under such circumstances, finally will not execute, so it will generateProgramThe lock leaks, and the program may have a dead lock. If there is no difference between non-optimization and optimization building, this problem does not exist.

However. In this solution, [Note: C #4.0 is to move monitor. Enter () to the try clause, and a reference value will be passed during enter to identify whether the lock is occupied. In the finnally clause, the system first checks whether the lock is occupied. If it is occupied, the lock is released.] It also has its own problems. According to Eric, "compared to being consistent and not consistent, it is totally 50 steps. It still has a lot of questions... the code generated in this way [NOTE: The generated code means that the compiler converts lock to Il, actually, it is equivalent to using the monitor syntax] the implicit meaning is that the deadlock program is the worst possible thing. This statement may not be accurate ."

The purpose of the lock is to protect variable resources, or, in other words, to prevent multiple potential users of variable resources from accessing the damaged version of the resource. The existing solution of Version 4.0 does not include the ability to roll back to the original state, nor guarantee the integrity of variable resources. Forcibly entering the finally clause of the lock statement, releasing the lock, and allowing access to any waiting thread (the thread occupies the destroyed resources) may cause exceptions. This solution compromises the consistency of the results, reduces the possibility of deadlocks, and the possible cost of the compromised access status. This problem is especially risky in multithreaded programming.

This particular compromise is the choice of two bad results: Program deadlock, or no longer protecting the status of important resources. The so-called "two evils take their light". When we program multithreading, we must make a choice among multiple design decisions and trade-offs.

This articleArticleSome developers think that this type of design problem is not limited to multithreading, but there are also differences between "security lock" and "security exception. Lippert also agrees that multithreading will only make the hard-to-solve problem more difficult. "obtaining a lock is only the first step in the long journey." Your design also needs to consider other exceptions, and how to handle exceptions. A large number of respondents pointed out the danger of terminating the thread, and partially agreed that "the termination exception is purely seeking death" by lippert ".

View Original English text:C #4.0 "fixes" deadlock issue