Fix a potential lost wakeup for binlog_commit_wait_usec

If a transaction T1 needs to wait for a transaction T2, T2's commit will skip the normal binlog_commit_wait_usec delay, in order not to needlessly stall throughput. This works by checking if T2 is already ready to commit. If so, it is woken up. If not, we set a flag in T2 so that when it gets ready to commit, it will do so immediately. But there was a potential race due to insufficient locking, if T2 gets ready to commit just at the point where T1 does the check. If the race hits, the wakeup (and early commit) of T2 might be lost. The race is only theoretical (from code inspection, no known test case), but seems best to fix it anyway, by properly locking LOCK_prepare_ordered around the check.

Author: knielsen

sql/log.cc

@@ -7664,14 +7664,13 @@ void
 MYSQL_BIN_LOG::binlog_trigger_immediate_group_commit()
 {
  group_commit_entry *head;
- mysql_mutex_lock(&LOCK_prepare_ordered);
+ mysql_mutex_assert_owner(&LOCK_prepare_ordered);
  head= group_commit_queue;
  if (head)
  {
  head->thd->has_waiter= true;
  mysql_cond_signal(&COND_prepare_ordered);
  }
- mysql_mutex_unlock(&LOCK_prepare_ordered);
 }
 
 
@@ -7690,9 +7689,11 @@ binlog_report_wait_for(THD *thd1, THD *thd2)
 {
  if (opt_binlog_commit_wait_count == 0)
  return;
+ mysql_mutex_lock(&LOCK_prepare_ordered);
  thd2->has_waiter= true;
  if (thd2->waiting_on_group_commit)
  mysql_bin_log.binlog_trigger_immediate_group_commit();
+ mysql_mutex_unlock(&LOCK_prepare_ordered);
 }