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.

To keep things simple, this section only discusses multi-process programs. You can do the same types of operations when debugging multi-threaded programs.

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, grouping all held processes under Breakpoint in the first column.