Because threads and processes are often executing different instructions, keeping threads and processes together is difficult. The best strategy is to define places where the program can run freely and places where you need control. This is where barrier points come in.
If you set a breakpoint that stops all processes when it is hit and you let your processes run using the
Group > Go command, you might get lucky and have all of your threads reach the breakpoint together. More likely, though, some processes won’t have reached the breakpoint and TotalView will stop them wherever they happen to be. To get your processes synchronized, you would need to find out which ones didn’t get there and then individually get them to the breakpoint using the
Process > Go command. You can’t use the
Group > Go command since this also restarts the processes stopped at the breakpoint.
If you set the breakpoint’s property so that only the process hitting the breakpoint stops, you have a better chance of getting all your processes there. However, you must be careful not to have any other breakpoints between where the program is currently at and the target breakpoint. If processes hit these other breakpoints, you are once again left to run processes individually to the breakpoint.
Single stepping is just too tedious if you have a long way to go to get to your synchronization point, and stepping just won’t work if your processes don’t execute exactly the same code.
If you use a barrier point, you can use the Group > Go command as many times as it takes to get all of your processes to the barrier, and you won’t have to worry about a process running past the barrier.
The Root Window shows you which processes have hit the barrier. It marks all held processes with the letter
H (meaning hold) in the column immediately to the right of the state codes. When all processes reach the barrier, TotalView removes all holds.