From 7781cdb79bccef16e800d67eeade031e65967e82 Mon Sep 17 00:00:00 2001 From: unknown Date: Tue, 17 Sep 2013 11:33:29 +0200 Subject: [PATCH] MDEV-4506: parallel replication. Add comments explaining tricky memory barrier semantics and suggestions for future changes. --- sql/log.cc | 12 ++++++++++++ sql/sql_class.cc | 13 +++++++++++++ 2 files changed, 25 insertions(+) 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);