Reprint The experience of C + + project avoiding thread deadlock

A few days ago, people asked: If multithreaded routines appear deadlock, how to do? Suddenly, I felt unable to answer. In the program I have written, it seems that there has not been a simple deadlock problem. I also wrote a lot of multithreaded programs, more complex, more than 10 threads entangled with each other, why has not been a deadlock? Must be some of my actions, to be able to effectively avoid deadlocks, to find them out, will be valuable. So, I have recently written some of the project code out, carefully examined again.
Multithreading occurred deadlock, nothing but the bowl, looking at the pot, if you can avoid this, natural will not happen to deadlock. Yet it is not so easy to show the world. Let's start with the latest project.
First, the recent project used Boost.thread as a line threading, and it was thought that a very good library might not be strong enough, but it was not strong enough to make the code more robust. Combining Boost.bind, creating threads becomes simple and straightforward, Eliminates the possibility of resource leaks during thread exception exits and thread creation. Through bind, we can easily use raii without having to worry about the transfer of resource ownership. The only thing to be aware of: The thread execution unit relies on an object that is longer than the thread. We have not been able to implement a mechanism to ensure this in the previous project, and we did have a hidden error associated with this issue on this issue.
Conclusion: It is very important to select a reliable line threading.
Second, for the use of locks, the entire project has only one raii use form. The importance of using RAII to ensure the alignment of locks cannot be overemphasized. In fact, we also use a single locking syntax. It is still implemented using the locks provided by the boost.thread.
Conclusion: The lock must be manipulated by RAII.
Third, there is no direct manipulation of raw resources that exist competition, for competing resources, all provide a non competitive interface, which is achieved through an indirect layer. An indirect layer of access to resources is added, avoiding the acquisition of high-level code control resources as much as possible. In addition, because the indirect layer is implemented for each resource type, Avoids the situation where a lock controls access to multiple resources. For the need to obtain more than one resource, the acquisition logic is extracted at a higher level, providing a unified resource acquisition logic, while in the realization of the internal, ensure the orderly acquisition of resources, the algorithm to avoid deadlock.
Conclusion: Provide abstraction for competitive access of resources and mask details.
I think, stick to these three points, should be able to avoid most of the thread deadlock problem.

In addition, it is important to keep a consistent order when acquiring locks, which is also a textbook method for avoiding deadlocks and is very effective.