Sorry for a most probably totally off-topic post in regards to the OP:s request, but this is a short description of some methods to get multiple processors to synchronize to serial data in an easy way and without expensive hardware.

When the timing requirements are low, it will be enough to just let the ISR put received characters into a receive buffer and when the main loop detects a suitable character, it starts performing the trigged action. Depending on the iteration speed of the main loop, this may give ms-scale jitter.

For better results, the UART ISR can be extended to contain the code to detect the trigger character and perform the required action. This will reduce the jitter to basically depend on the baudrate generator speed. If the UART runs the bit sampling at 16x the baudrate, the chip would sample the start bit at 16*9600 Hz or every 6.5us. If we assume two sample periods for jitter that would mean 13us jitter plus jitter from entering the ISR (nesting problems, instruction timing, interrupts disabled, ...). Having chips with +/- 1% RC oscillators and an ISR that takes 100us until a result is produced, the oscillator would add 2us extra. Stepping up from 9600 baud to 115200 baud, the 2 bit sampling periods would shrink from 13 to 1.1us.

If there is a need to reduce the jitter from the processor being busy with other interrupts or in a critical section with interrupts disabled, the serial activation can be updated to a two-step operation. The first serial character sent out is used as a "PREPARE" to warn the chip that a time-critical activation is getting near. The chip can then deactivate other interrupts and start a single timer of a couple of character intervals as a timeout. It then either enters a busy loop or - if possible - performs some form of 'halt' or similar where the processor core is stopped until the next interrupt arrives. If the next interrupt is the timer, then there was a problem and the processor can recover gracefully from the timeout. If the next interrupt is the UART receive detecting a "GO" character, then the UART ISR will only be affected by the varying latency depending on what instruction it was currently processing in the loop, so the jitter entering the ISR would be down to machine cycles.

Obviously, when getting the ISR activation jitter down to machine cycles, the two big error sources would be an RC oscillator, and the frequency of the baudrate generator. Using a cheap 100ppm crystal would reduce jitter from a 100us computation into +/- 10ns instead of +/- 1us.

The easist way to reduce the baudrate-induced jitter is to send the "READY" character as standard serial data, but then rely on a handshake signal to produce some form of pin-change interrupt for the "GO" signal. With this change, the input trigger would no longer be sampled at the baudrate generator speed but often the main oscillator speed or sometimes scaled by a PLL for even higher sampling rates. And since the "GO" signal is now just a toggled digital signal, it works just as well to get a single processor to start an action with quite low jitter.

So in the end, a trivially cheap microcontroller with a trivially cheap RC oscillator can manage us-level jitter while being self-synchronizing. And having a low-quality crystal, it is possible to drop the jitter to a couple of machine cycles, as long as the evaluation in the ISR doesn't performs conditional jumps depending on received command data or state of input pins. For the least jitter, computations should make use of lookup tables or the computations should be written in constant path-length form. More advanced processors should have code and data caches disabled, to remove variance introduced by earlier code execution.

When the requirements are to manage jitter less than a couple of machine cycles, then the logic solution is to avoid using a processor or to (depending on iteration speed of commands/control loop) introduce hardware buffering to dejitter computed results. One issue here is of course that at ns/GHz standard silicon gets into troubles with bandwidth/rise times. Especially if the external signals can't be run at very low voltages. But anyone requiring concurrency in these time ranges would not ask questions on this forum about how a PC could communicate serially with two 8051 chips.