MDEV-4506: parallel replication.

Add comments explaining tricky memory barrier semantics and
suggestions for future changes.

2 files changed, 25 insertions, 0 deletions

diff --git a/sql/log.cc b/sql/log.cc
index 763eb4177ea..ccedaa90ec6 100644
--- a/sql/log.cc
+++ b/sql/log.cc
@@ -6757,6 +6757,18 @@ MYSQL_BIN_LOG::queue_for_group_commit(group_commit_entry *entry)
     {
       if (list->wakeup_subsequent_commits_running)
       {
+        /*
+          ToDo: We should not need a full lock/unlock of LOCK_wait_commit
+          here. All we need is a single (full) memory barrier, to ensure that
+          the reads of the list above are not reordered with the write of
+          wakeup_subsequent_commits_running, or with the writes to the list
+          from other threads that is allowed to happen after
+          wakeup_subsequent_commits_running has been set to false.
+
+          We do not currently have explicit memory barrier primitives in the
+          source tree, but if we get them the below mysql_mutex_lock() could
+          be replaced with a full memory barrier just before the loop.
+        */
         mysql_mutex_lock(&list->LOCK_wait_commit);
         list->wakeup_subsequent_commits_running= false;
         mysql_mutex_unlock(&list->LOCK_wait_commit);
diff --git a/sql/sql_class.cc b/sql/sql_class.cc
index 66b28c87ac9..9a638947257 100644
--- a/sql/sql_class.cc
+++ b/sql/sql_class.cc
@@ -5754,6 +5754,19 @@ wait_for_commit::wakeup_subsequent_commits2()
     waiter= next;
   }
 
+  /*
+    ToDo: We should not need a full lock/unlock of LOCK_wait_commit here. All
+    we need is a (full) memory barrier, to ensure that the reads of the list
+    above are not reordered with the write of
+    wakeup_subsequent_commits_running, or with the writes to the list from
+    other threads that is allowed to happen after
+    wakeup_subsequent_commits_running has been set to false.
+
+    We do not currently have explicit memory barrier primitives in the source
+    tree, but if we get them the below mysql_mutex_lock() could be replaced
+    with a full memory barrier. It is probably not important, the lock is not
+    contented and will likely be in the CPU cache since we took it just before.
+  */
   mysql_mutex_lock(&LOCK_wait_commit);
   wakeup_subsequent_commits_running= false;
   mysql_mutex_unlock(&LOCK_wait_commit);