-
Notifications
You must be signed in to change notification settings - Fork 537
Fix action server deadlock (#1285) #1313
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
Merged
Merged
Changes from 7 commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
760c980
add a test case to reproduce deadlock situation in rclcpp_action
daisukes d2bd783
unlock action_server_reentrant_mutex_ before calling user callback fu…
daisukes e1ee318
Revert "unlock action_server_reentrant_mutex_ before calling user cal…
daisukes 6feedbe
minimize lock scopes to avoid deadlock
daisukes 054bf57
remove an unnecessary lock
daisukes 5ae0e9a
make action_server_reentrant_mutex_ scope smaller
daisukes ca4c851
Merge remote-tracking branch 'master' into foxy
daisukes 5adb529
use std::atomic<bool> to make pimpl flags to atomic
daisukes File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
I don't think we need this particular lock here. At least, this lock is meant to protect the
action_server, and that is not being accessed here.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.
rclcpp/rclcpp_action/src/server.cpp
Line 526 in 6feedbe
goal_handles_ can be changed simultaneously, so I put a lock guard here too.
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.
I'm sorry to be a bit pedantic here, but the name of the lock is currently
action_server_reentrant_mutex. As a reader of the code, then, I expect that that lock will protect theaction_server, and not necessarily protect anything else.But I do agree that the
goal_handlescould be changed by two separate threads. There are 2 ways we can go with this:pimpl_lockor something like that. At that point, it makes more sense that the lock protects the entire PIMPL structure. But we would also need to audit the rest of the code to make sure that the lock is being held anytime anything in the structure is being modified.goal_handles, and lock that as appropriate.I'm honestly not sure which is better.
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.
I missed this message and have made a change, but I added another mutex for unordered maps including goal_handles, because the pimpl structure has three groups of variables, 1) action_server and its attributes (size_t, bool) captured from actsion_server, 2) three unordered maps, and 3) references (clock and logger).
I think we don't need to lock the entire pimpl structure.
One line I'm not sure about is updating goal_request_ready_ without a lock.
All size_t and bool variables are protected because they are updated with action_server.
rclcpp/rclcpp_action/src/server.cpp
Line 292 in 5ae0e9a
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.
Good question. It should be atomic since it is just updating a boolean, but that is not guaranteed. One thing we could do there is make it a
std::atomic<bool>, which would guarantee it.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.
Thanks for the suggestion! I changed it to
std::atomic<bool>.