Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix a few thread sanitizer failures #5643

Merged
merged 2 commits into from
Jul 7, 2022
Merged

Fix a few thread sanitizer failures #5643

merged 2 commits into from
Jul 7, 2022

Conversation

tgoyne
Copy link
Member

@tgoyne tgoyne commented Jul 2, 2022

The emulated implementation of InterprocessCondVar requires that the associated mutex be held when notify_all() is called because it performs non-atomic reads and writes on the shared part, which would be a data race if done without a mutex covering the access. This is already noted as a precondition of the function, which DB::do_end_write() violated.

Calling DB::set_replication() inside a write transaction is almost safe to do, but it turns out that there's a few scenarios where the sync client will call DB::get_replication() outside of a write. Scoping the replication setting to just the specific Table fixes this (as live Table accessors actually are thread-confined) and also simplifies the logic a bit.

@tgoyne tgoyne self-assigned this Jul 2, 2022
@cla-bot cla-bot bot added the cla: yes label Jul 2, 2022
@@ -2577,7 +2575,6 @@ DisableReplication::DisableReplication(Transaction& t)
, m_version(t.get_version())
{
m_owner->set_replication(nullptr);
t.get_version();
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was just a no-op.

tgoyne added 2 commits July 6, 2022 11:33
The emulated implementation of InterprocessCondVar requires that the associated
mutex be held when `notify_all()` is called because it performs non-atomic
reads and writes on the shared part, which would be a data race if done without
a mutex covering the acceses. This is already noted as a precondition of the
function, which DB::do_end_write() violated.
Calling `DB::set_replication()` inside a write transaction is _almost_ safe to
do, but it turns out that there's a few scenarios where the sync client will
call `DB::get_replication()` outside of a write. Scoping the replication
setting to just the specific Table fixes this (as live Table accessors actually
are thread-confined) and also simplifies the logic a bit.
@tgoyne tgoyne marked this pull request as ready for review July 6, 2022 19:51
@tgoyne tgoyne requested a review from ironage July 6, 2022 22:57
@tgoyne tgoyne merged commit 7b5282f into master Jul 7, 2022
@tgoyne tgoyne deleted the tg/tsan branch July 7, 2022 03:31
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 22, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants