-
Notifications
You must be signed in to change notification settings - Fork 338
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
Thread safety #101
base: master
Are you sure you want to change the base?
Thread safety #101
Conversation
I'm surprised this PR has been sitting for so long! It seems to fix a quite dangerous bug! It seems to have an occasional deadlock problem I tried to investigate, but its going to be a non-obvious one. My guess is that one of the threads must hang after acquiring goal_mutex or something. |
Any progress on this? |
Not that I'm aware of. This PR is also targeting |
This PR has been merged into this fork of |
@jaymwong wrote:
that fork is also based on the deprecated |
This PR addresses some thread safety and race conditions present in the trajectory action server.
The problems/fixes include:
has_goal_
is accessed fromdoTraj()
and the action server callbacks, so protect it by a mutex.goalCB()
andcancelCB()
also have to be protected against affecting each other, since an async spinner with 3 threads is used - the action server itself does not provide any locking.UrRealtimeCommunication
class is not thread-safe. If you calladdCommandToQueue()
from a different thread (e.g. the trajectory thread inUrDriver::uploadProg()
), you can get data corruption.There are other subtle changes (joining the trajectory thread properly, ...).
@ThomasTimm, we talked briefly at MBZIRC about your driver. If you want, I can spend some more time on separating the changes so that they are easier for you to check. Does that make sense or will you release your new version soon?