Bug#11766349 - 59443: query_cache_debug.test is occasionally very slow

The test case problem stemmed from the fact that a debug sync
signal is a global variable that persists until overwritten
by a new signal. This means that if two different signals
are raised in sequence, a thread waiting for the first signal
might miss it if the second signal sets the global variable
before the thread wakes up.

The solution is to deliver a subsequent signal only after the
waiting thread has received it.

mysql-test/t/query_cache_debug.test:
  Wait for signal to be delivered.

1 files changed, 10 insertions, 0 deletions

diff --git a/mysql-test/t/query_cache_debug.test b/mysql-test/t/query_cache_debug.test
index 2f85813d1ef..70b3c81168d 100644
--- a/mysql-test/t/query_cache_debug.test
+++ b/mysql-test/t/query_cache_debug.test
@@ -208,7 +208,17 @@ SET DEBUG_SYNC="now WAIT_FOR parked1_2";
 --echo ** until a broadcast signal reaches them causing both threads to 
 --echo ** come alive and check the condition.
 SET DEBUG_SYNC="now SIGNAL go2";
+--echo ** Wait for thd2 to receive the signal
+let $wait_condition=
+  SELECT COUNT(*) = 1 FROM information_schema.processlist
+  WHERE state = "Waiting for query cache lock";
+--source include/wait_condition.inc
 SET DEBUG_SYNC="now SIGNAL go3";
+--echo ** Wait for thd3 to receive the signal
+let $wait_condition=
+  SELECT COUNT(*) = 2 FROM information_schema.processlist
+  WHERE state = "Waiting for query cache lock";
+--source include/wait_condition.inc
 
 --echo **
 --echo ** Finally signal the DELETE statement on THD1 one last time.