调试同步点让用户级锁定能够在代码中的任意点进行同步。

open_tables(…)DBUG_SYNC_POINT(“debug_lock。after_open_tables”,10);lock_tables(…)

同步点的行为类似于

RELEASE_LOCK(<任何线程拥有>);IS_FREE_LOCK(str) OR GET_LOCK(str,timeout) AND RELEASE_LOCK(str)

这意味着同步点释放该线程可能拥有的任何锁，如果另一个线程拥有该锁，则等待获取该锁，并立即释放它。如果锁是空闲的(没有被任何线程使用)，同步点只会释放当前线程的任何用户级锁。

所以DBug_sync_point的想法是，当用户级锁不被任何线程不使用时，它不做任何事情，并且在使用时等待它变为自由。这样，您可以通过获取用户级锁来阻止在同步点处的线程，并通过释放锁定继续。

这可以作为一种“信号”。线程获取一个锁(“信号”锁)，并在到达同步点时隐式释放它。另一个线程试图在这个线程之后获得“信号”锁，在同一时刻获得锁，可以继续。

它可以被用作“等待”。另一个线程有“同步点”锁(“debug_lock”)。这个线程在同步点上阻塞了它。

不幸的是，我没有弄明白，如何使用它的“信号”_plus_“等待”。而其他线程可以“同步点”锁,线程锁“信号”,从而达到同步点释放的“信号”锁等“同步点”锁,其他线程无法等待“信号”锁,锁,因为它有“同步点”。一个线程只能有一个用户锁。当另一个线程试图等待“信号”锁时，它会隐式地释放“同步点”锁。如果可以确保这个线程在另一个线程释放“同步点”锁之前到达同步点，那么这就没问题了。否则在同步点不会发生等待。这个测试不会测试它应该测试的东西。

一个可能的解决方案可能是第三个线程，它在开始时获得“同步点”锁，并在适当的时候释放它。但是对于更复杂的情况，这很容易导致大量线程。使用这种方法的测试很可能变得难以理解。

DBUG_SYNC_POINT无条件释放任何锁可能是实现中的一个bug。这种方法没有得到广泛的应用。我发现sql_repl.cc只有一次使用。我猜添加锁释放是为了防止同步点在线程自己的锁上等待。如果该方法能找到更多的用途，那么这种行为可以很容易地得到修正。

DBUG_SYNC_POINT方法仅在调试服务器中可用。如果在测试套件中使用它，则必须采取“bug睡眠”一节中提到的编写测试的类似预防措施。