Fix ABBA deadlock between waitForTransform and testTransformableRequests (backport #982) - #990
Conversation
|
Cherry-pick of 16cfc11 has failed: To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally |
Signed-off-by: Alejandro Hernandez Cordero <ahcorde@gmail.com>
|
Pulls: #990 |
|
Pulls: #990 |
Description
As mentioned in #979, an ABBA deadlock situation was introduced in #966 where
testTransformableRequests()lockstransformable_requests_mutex_and tries to run cb which requirestimer_to_request_map_mutex_while parallelywaitForTransformacquirestimer_to_request_map_mutex_and tries to calladdTransformableRequestwhich internally needstransformable_requests_mutex_resulting in ABBA situation.My apologies for not noticing this issue previously and a special thanks to @jplapp and @mini-1235 for bringing it to my attention.
@mini-1235 has already opened #979 to fix this issue. I agree with the approach in that PR (to unlock mutex before running callbacks and lock again) but I think restarting the
iand going through the beginning of the requests for every callback would add unnecessary computation time. More precisely, the cost is that if M callbacks fire persetTransformand N requests are pending, you get O(M·N) work instead of O(N).I tried to improve that by going through the requests first, extracting the pending callbacks and then running them. That way we keep the swap-and-pop behavior as before.
I have also copied the test @jplapp added in #980 here as well. @mini-1235 could you please also check this in your nav2 setup where this problem became highlighted?
Credits to @jplap and @mini-1235 for their idea and suggested changes.
Did you use Generative AI?
Yes, Claude Sonned 4.6
This is an automatic backport of pull request #982 done by [Mergify](https://mergify.com).