1. Diagrams that help visualize what's happening. I prefer a hybrid of sequence, timeline and activity diagrams. I don't have a ready example at hand, but [1] comes close to what I use. YMMV though - I know some team members in my past jobs preferred state transitions to these, because they found them clearer to think through.
2. A technique we used during team reviews was borrowed from the book "Debugging Applications" by John Robbins [2]. Although the book was about debugging Windows applications, it had good tips on general software engineering and debugging, and I still recommend it now. One technique in it was the multithread simulation review - an excerpt:
The trick is to assign one person to each thread in your code and one person to each synchronization object. When you review the code, pretend that each thread is running at realtime priority on its own dedicated CPU. Each "thread person" walks through the code paying attention only to the particular code that his thread is supposed to be executing. When the "thread person" is ready to acquire a synchronization object, the "object person" literally moves behind the "thread person." When the "thread person" releases a synchronization object, the "object person" goes to a neutral corner of the room. In addition to the thread and object representatives, you should have some developers who are monitoring the overall thread activity so that they can assess the program's flow and help determine the points at which different threads deadlock.
Obviously, you need a number of like-minded and enthusiastic team members to carry it off.
1. Diagrams that help visualize what's happening. I prefer a hybrid of sequence, timeline and activity diagrams. I don't have a ready example at hand, but [1] comes close to what I use. YMMV though - I know some team members in my past jobs preferred state transitions to these, because they found them clearer to think through.
2. A technique we used during team reviews was borrowed from the book "Debugging Applications" by John Robbins [2]. Although the book was about debugging Windows applications, it had good tips on general software engineering and debugging, and I still recommend it now. One technique in it was the multithread simulation review - an excerpt:
The trick is to assign one person to each thread in your code and one person to each synchronization object. When you review the code, pretend that each thread is running at realtime priority on its own dedicated CPU. Each "thread person" walks through the code paying attention only to the particular code that his thread is supposed to be executing. When the "thread person" is ready to acquire a synchronization object, the "object person" literally moves behind the "thread person." When the "thread person" releases a synchronization object, the "object person" goes to a neutral corner of the room. In addition to the thread and object representatives, you should have some developers who are monitoring the overall thread activity so that they can assess the program's flow and help determine the points at which different threads deadlock.
Obviously, you need a number of like-minded and enthusiastic team members to carry it off.
[1]: http://community.qnx.com/sf/wiki/do/viewAttachment/projects....
[2]: https://www.amazon.com/Debugging-Applications-DV-MPS-Program...