database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-08-09 22:24:09 +03:00
Code Activity

MDEV-4506: parallel replication.

Browse Source 
Add comments explaining tricky memory barrier semantics and
suggestions for future changes.
This commit is contained in:
unknown
2013-09-17 11:33:29 +02:00
parent 5633dd8227
commit 7781cdb79b
2 changed files with 25 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
sql/log.cc
View File

@@ -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);

13
sql/sql_class.cc
View File

@@ -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);