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

MDEV-4506: parallel replication.

Remove some unnecessary mutex locking.
This commit is contained in:
unknown
2013-09-23 10:22:46 +02:00
parent c168c49d77
commit 5d1d20e409
2 changed files with 23 additions and 31 deletions

View File

@@ -5624,6 +5624,10 @@ wait_for_commit::wakeup()
Otherwise we would need to somehow ensure that they were done
waking up before we could allow this THD to be destroyed, which would
be annoying and unnecessary.
Note that wakeup_subsequent_commits2() depends on this function being a
full memory barrier (it is, because it takes a mutex lock).
*/
mysql_mutex_lock(&LOCK_wait_commit);
waiting_for_commit= false;
@@ -5755,21 +5759,15 @@ wait_for_commit::wakeup_subsequent_commits2()
}
/*
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 need a full memory barrier between walking the list above, and clearing
the flag wakeup_subsequent_commits_running below. This barrier is needed
to ensure that no other thread will start to modify the list pointers
before we are done traversing the list.
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.
But wait_for_commit::wakeup() does a full memory barrier already (it locks
a mutex), so no extra explicit barrier is needed here.
*/
mysql_mutex_lock(&LOCK_wait_commit);
wakeup_subsequent_commits_running= false;
mysql_mutex_unlock(&LOCK_wait_commit);
}