-
Notifications
You must be signed in to change notification settings - Fork 411
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 data race in tunnel_set/receiver_set and establish call data #5650
Fix data race in tunnel_set/receiver_set and establish call data #5650
Conversation
Signed-off-by: xufei <[email protected]>
Signed-off-by: xufei <[email protected]>
[REVIEW NOTIFICATION] This pull request has been approved by:
To complete the pull request process, please ask the reviewers in the list to review by filling The full list of commands accepted by this bot can be found here. Reviewer can indicate their review by submitting an approval review. |
} | ||
LOG_FMT_TRACE(log, "waiting consumer finish!"); | ||
waitForSenderFinish(/*allow_throw=*/false); | ||
close(""); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In MPPTask's destruct, it will close all tunnels, so it is safe to make this change.
tiflash/dbms/src/Flash/Mpp/MPPTask.cpp
Lines 67 to 74 in b6536f6
MPPTask::~MPPTask() | |
{ | |
/// MPPTask maybe destructed by different thread, set the query memory_tracker | |
/// to current_memory_tracker in the destructor | |
if (current_memory_tracker != memory_tracker) | |
current_memory_tracker = memory_tracker; | |
closeAllTunnels(""); | |
if (schedule_state == ScheduleState::SCHEDULED) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if one of tunnels throw error in tunnel::close()
when closeAllTunnels
is called? Is it safe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MPPTunnel::close()
should not throw error, if it throws error, I think maybe the TiFlash server will be terminated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
/merge |
@yibin87: It seems you want to merge this PR, I will help you trigger all the tests: /run-all-tests You only need to trigger If you have any questions about the PR merge process, please refer to pr process. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository. |
This pull request has been accepted and is ready to merge. Commit hash: 2d9d10b
|
/run-unit-test |
@windtalker: Your PR was out of date, I have automatically updated it for you. At the same time I will also trigger all tests for you: /run-all-tests If the CI test fails, you just re-trigger the test that failed and the bot will merge the PR for you after the CI passes. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository. |
/rebuild |
/run-integration-test |
Coverage for changed files
Coverage summary
full coverage report (for internal network access only) |
Signed-off-by: ti-chi-bot <[email protected]>
In response to a cherrypick label: new pull request created: #5652. |
What problem does this PR solve?
Issue Number: ref #5095, close #5651
Problem Summary:
In Some refinements of
mpp_exchange_receiver_map
andMPPTunnelSet
#5132, it try to use the atomic variablestatus
to protect tunnel_set/receiver_set in multiple thread read/write(MPPTask::runImpl thread to write and MPPTask::abort thread to read):tiflash/dbms/src/Flash/Mpp/MPPTask.cpp
Lines 145 to 147 in b6536f6
Unfortunately, it turns out not working becase the value of
status
can be changed after L145 and before L147tiflash/dbms/src/Flash/EstablishCall.cpp
Lines 106 to 113 in b6536f6
After
write(packet)
in L109, the call data is put back to completion queue, and it can be deleted anytime, so there is a chance that before executing L110, the call data itself has been deleted.What is changed and how it works?
write(packet)
, sincewrite(packet)
always return true, just seterr_status
toOK
beforewrite(packet)
Check List
Tests
run random failpoint tests
Side effects
Documentation
Release note