In concurrent programming, Yancheng computer training/suggestion deadlock is a very common logical error.
Deadlock is not difficult to avoid with correct programming methods.
Four Necessary Conditions of Deadlock In the textbooks for computer majors, four necessary conditions of deadlock are usually introduced.
These four conditions are indispensable, or as long as any one of them is destroyed, deadlock is impossible.
Let's review these four conditions: mutual exclusion: there is such a resource that can only be allocated to one thread (also called thread) at a certain time; Hold: When the requested resource has been occupied, resulting in thread blocking, the resource occupier not only does not need to release the resource, but also can continue to request more resources; Nopreemption: mutually exclusive resources obtained by a thread cannot be forcibly deprived, in other words, only resource occupiers can release resources; Circularwait: Several threads acquire mutually exclusive resources in different order, thus forming a circular wait situation. Imagine that in a circular chain composed of multiple threads, each thread is waiting for the next thread to release the resources it holds.
It is not difficult to see the necessary conditions for deadlock. Among the four necessary conditions of deadlock, the second, third and fourth conditions are relatively easy to eliminate.
By introducing trading mechanism, the second and third conditions can often be eliminated. The method is to treat all locking operations as transactions, and once locking is started, ensure that all operations can be rolled back. At the same time, the lock manager can detect deadlocks and deprive resources (rollback transactions).
This practice sometimes causes a lot of overhead, and more changes are needed to the locking mode.
Eliminating the fourth condition is an easier and cheaper way.
Specifically, this method stipulates that the locking order must be consistent.
Specifically, we artificially give the lock a direction attribute, similar to "water level".
No matter what locks have been held, all locking operations of a thread must be executed from low to high (or from high to low) in a consistent order, and only one order is allowed in a system.
Note that the order in which locks are placed does not lead to deadlock.
That is to say, although it seems strange to lock in the order of lock A, lock B, put A and put B, as long as everyone locks in the order of A first and then B, it will not lead to deadlock.
Solution: When using a transaction in 1, try to shorten the logical processing process of the transaction, and commit or rollback the transaction as soon as possible (refine the processing logic, execute a section of logic and then rollback or commit, and then execute other logic until the transaction is committed); 2. Set the deadlock timeout parameter in a reasonable range, such as: 3 minutes-10 minutes; If it is exceeded, the operation is automatically abandoned to avoid the process hanging; ? 3. Optimize the program, check and avoid deadlock; ? All scripts and SP should be carefully tested before the exact version.
5 All SP should have error handling (through @error)? 6 generally do not modify the default level of SQLSERVER transactions.
Forced locking is not recommended. Another reference solution: access objects in the same order. If all concurrent transactions access objects in the same order, the possibility of deadlock will be reduced.
For example, if two concurrent transactions get a lock on the supplier table and then a lock on the parts table, the other transaction is blocked on the supplier table before one of the transactions is completed.
After the first transaction commits or rolls back, the second transaction continues.
There will be no deadlock.
Using stored procedures for all data modifications can standardize the order of accessing objects.