Why should I use barrier points instead of breakpoints when debugging multi-process and multi-threaded programs?
Because threads and processes can be doing different things, keeping things together is difficult. The best strategy is to define places where the program can run freely and places where you need to keep things under control. This is where barrier points come in. To keep things simple, I’ll only talk about multi-process programs. The same things are true for multi-threaded programs. Why breakpoints don’t work (part 1) If you set a breakpoint that stops all processes when it is hit and you let your processes run using Group > Go, you can get lucky and all of them will be at the breakpoint. What’s more likely is that some processes won’t have reached the breakpoint and TotalView will have stopped them wherever they happen to be. To get things synchronized, you’ll need to find out which ones didn’t get there and then individually get them to the breakpoint using Process > Go. You can’t use Group > Go as this will also run the processes stopped at the breakpoint. Why breakpoints don’t work
Related Questions
- Can I combine the points I earn on my ValueBank Texas Discover Debit Card with those earned in frequent-flyer programs or on other mileage cards?
- What are the usual selling points that commercial dental financing and credit programs feature?
- What other point based timeshare programs have a Points For Deposit opportunity?
