MDEV-10804 main.stat_tables_par fails sporadically in buildbot

This was because of two issues:
- thr_multi_lock_after_thr_lock needed to be hit 3 times before go2 could
  be signaled, because 2 of these happened before statistics_update_start
  was reached.
- The original code didn't take into accunt that thr_locks can be executed in
  any random order, which caused sporadic failures when waiting for 1 lock
  of 3, as if the locks where in different order, there would be a dead-lock.
  Fixed by introducing thr_multi_lock_before_thr_lock which is deterministic.
- Some of the test failures where not noticed as the DEBUG_SYNC timeout
  would cause the test to pass (after 300 seconds).

1 files changed, 2 insertions, 1 deletions

diff --git a/mysys/thr_lock.c b/mysys/thr_lock.c
index c168957097f..25113670015 100644
--- a/mysys/thr_lock.c
+++ b/mysys/thr_lock.c
@@ -1288,6 +1288,7 @@ thr_multi_lock(THR_LOCK_DATA **data, uint count, THR_LOCK_INFO *owner,
     DBUG_RETURN(THR_LOCK_SUCCESS);
 
   /* lock everything */
+  DEBUG_SYNC_C("thr_multi_lock_before_thr_lock");
   for (pos=data,end=data+count; pos < end ; pos++)
   {
     enum enum_thr_lock_result result= thr_lock(*pos, owner, lock_wait_timeout);
@@ -1299,12 +1300,12 @@ thr_multi_lock(THR_LOCK_DATA **data, uint count, THR_LOCK_INFO *owner,
         (*pos)->type= TL_UNLOCK;
       DBUG_RETURN(result);
     }
-    DEBUG_SYNC_C("thr_multi_lock_after_thr_lock");
 #ifdef MAIN
     printf("Thread: %s  Got lock: 0x%lx  type: %d\n",my_thread_name(),
 	   (long) pos[0]->lock, pos[0]->type); fflush(stdout);
 #endif
   }
+  DEBUG_SYNC_C("thr_multi_lock_after_thr_lock");
 
   /*
     Call start_trans for all locks.