In cases where the normal server code does not have a block point at the critical place, one can insert an artificial synchronization point.

open_tables(...)
   
   DBUG_EXECUTE_IF("sleep_open_and_lock_after_open", {
     const char *old_proc_info= thd->proc_info;
     thd->proc_info= "DBUG sleep";
     my_sleep(6000000);
     thd->proc_info= old_proc_info;});
   
   lock_tables(...)

In this case, if the 'debug' keyword 'sleep_open_and_lock_after_open' is set, a thread sleeps for 6 seconds after open_tables() and before lock_tables(). Before sleeping, it sets the thread state (proc_info) to 'DBUG sleep'. The test file that uses this synchronization point looks like so:

--connection conn1
   let $conn1_id= `SELECT CONNECTION_ID()`;
   # System variable 'debug' exists only in debug servers
   --error 0, ER_UNKNOWN_SYSTEM_VARIABLE
   SET SESSION debug="+d,sleep_open_and_lock_after_open";
   send INSERT INTO t1 VALUES (1);
       --connection conn2
       # Specify the condition that shows if conn1 reached the sync point.
       let $wait_condition= SELECT 1 FROM INFORMATION_SCHEMA.PROCESSLIST
           WHERE ID = $conn1_id AND STATE = 'DBUG sleep';
       # Run the condition in a loop until it becomes true.
       --source include/wait_condition.inc
       # Run through the critical code.
       FLUSH TABLE t1;

So one can add synchronization points almost everywhere. But only at the cost of the wasted time of a sleep + a wait condition.

This method requires that you modify and recompile the server code. Another problem is that the synchronization point does not exist in non-debug servers. Not even the system variable 'debug' exists in a non-debug server. Each test must be written so that it works on a debug server as well as on a non-debug server. If this is not possible, the test must be moved into a test file that includes 'have_debug.inc'. Setting the possibly not existing variable can be protected by the --error 0, ER_UNKNOWN_SYSTEM_VARIABLE command. It says that the next statement can either succeed (0) or fail (ER_UNKNOWN_SYSTEM_VARIABLE).

Finally the method is bad when the execution should be traced with the DBUG facility. Setting one (or more) 'debug' keywords disables all other keywords. One would need to add a pretty long list for a meaningful trace.

The bottom line is: Use the "Dbug Sleep" method when there is no other way to repeat a problem. However, the "Debug Sync Facility" should be able to replace all "Dbug Sleep" synchronization points.