Fix data race in Actions: Part 2 #148
Merged
Conversation
This file contains 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
alsora
approved these changes
Aug 12, 2024
apojomovsky
pushed a commit
that referenced
this pull request
Aug 13, 2024
* Fixes for intra-process actions (#144) * Fixes for intra-process Actions * Fixes for Clang builds * Fix deadlock * Server to store results until client requests them * Fix feedback/result data race See ros2#2451 * Add missing mutex * Check return value of intra_process_action_send --------- Co-authored-by: Mauro Passerino <[email protected]> * Fix IPC Actions data race (#147) * Check if goal was sent through IPC before send responses * Add intra_process_action_server_is_available API to intra-process Client --------- Co-authored-by: Mauro Passerino <[email protected]> * Fix data race in Actions: Part 2 (#148) * Fix data race in Actions: Part 2 * Fix warning - copy elision --------- Co-authored-by: Mauro Passerino <[email protected]> * fix: Fixed race condition in action server between is_ready and take"… (ros2#2531) * fix: Fixed race condition in action server between is_ready and take" (ros2#2495) Some background information: is_ready, take_data and execute data may be called from different threads in any order. The code in the old state expected them to be called in series, without interruption. This lead to multiple race conditions, as the state of the pimpl objects was altered by the three functions in a non thread safe way. Co-authored-by: William Woodall <[email protected]> Signed-off-by: Janosch Machowinski <[email protected]> * fix: added workaround for call to double calls to take_data This adds a workaround for a known bug in the executor in iron. Signed-off-by: Janosch Machowinski <[email protected]> --------- Signed-off-by: Janosch Machowinski <[email protected]> Co-authored-by: Janosch Machowinski <[email protected]> Co-authored-by: William Woodall <[email protected]> --------- Signed-off-by: Janosch Machowinski <[email protected]> Co-authored-by: Mauro Passerino <[email protected]> Co-authored-by: jmachowinski <[email protected]> Co-authored-by: Janosch Machowinski <[email protected]> Co-authored-by: William Woodall <[email protected]>
This was referenced Aug 22, 2024
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The method used in #147 to verify if a goal was sent through inter or intra-process, was checking if the IntraProcessClient had the GoalID stored on the reponse buffers.
This approach didn't work in all scenarios, since the GoalID could be removed from the client even if the goal is still alive (after responses were processed).
The approach in this PR is similar - it also looks for the GoalID, but in the intra-process manager which has the goal ID stored for all the lifetime of the goal. So at any moment we can determine if the goal was or not sent though IPC.