The standard way for debuggers to plant interactive breakpoints in a program in RAM (whatever the processor instruction set) is to save the break pointed instruction and replace it by a jump to the breakpoint handling code. After the breakpoint is triggered, the saved instruction is restored in its original place in the code. If the interactive dialogue with the debugger during the breakpoint handling indicates that that the triggered breakpoint is to be removed, execution of the program can be resumed simply by jumping to the instruction that had been break pointed. However, if the dialogue with the debugger indicates that the breakpoint is to remain in place when execution of the program is resumed, implementation is more complicated. Execution of the saved instruction could be emulated, but this is difficult to do, ensuring all side effects such as condition code setting and exception triggering are performed correctly, as well as correctly simulating all addressing modes, such as PC relative. It is much easier simply to execute the break pointed instruction in place, but to plant another breakpoint on a subsequent instruction in the same basic block, usually the immediate successor to the original breakpoint, so that the breakpoint handler can regain control in order to replant the original breakpoint and remove the secondary one. This obviously has some challenges if the successor of the break pointed instruction cannot be statically predicted, for instance if the break pointed instruction is a conditional jump, but a common solution is simply to ban planting breakpoints on such instructions. Identify the critical races that exist with this scheme if the program is executed by multiple threads, possibly multiple cores or multiple processors. Use pseudo-code to illustrate how you would resolve these issues.