1
0
mirror of https://github.com/MariaDB/server.git synced 2025-08-08 11:22:35 +03:00

MDEV-4506: parallel replication.

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

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