-
Notifications
You must be signed in to change notification settings - Fork 77
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
Add Lock-free Queue #253
base: master
Are you sure you want to change the base?
Add Lock-free Queue #253
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #253 +/- ##
==========================================
+ Coverage 70.12% 71.67% +1.55%
==========================================
Files 8 9 +1
Lines 492 519 +27
Branches 84 85 +1
==========================================
+ Hits 345 372 +27
Misses 92 92
Partials 55 55
Flags with carried forward coverage won't be shown. Click here to find out more.
|
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.
TBH, I don't fully understand all the C++ specifics here 😬
But the API seems to be clean from a user perspective, looking at the tests.
- Does this replace the RealtimeBuffer? Or should the RealtimeBuffer be rewritten to use this queue with capacity of 1?
- What is the practical difference between the RealtimeBox and the queue with capacity of 1? Maybe this is clear for some, but I'd need (and appreciate) a user guide when to use what.
- If we deprecate something, we can also add migration notes to this repository and link it on control.ros.org
Co-authored-by: Christoph Fröhlich <[email protected]>
@christophfroehlich First of all, thanks for reviewing it
I believe yes, we can replace this with the RealtimeBuffer. Ideally, it should serve as a replacement. I wouldn't mix them to add backward compatibility. I think it is better to separate both approaches.
IMO, RealtimeBox is something you have to use, if you want to protect the data from concurrent access. For me, it is something to having the same thing protected by the mutex. However, to be frank I'm very skeptical of it being used with the shared_ptrs, because you can still access the contents outside of the RealtimeBox and this is couldn't be safe at all. Queue of capacity one might not be a good thing to use here, as it is meant to be used for buffer operations. Moreover, a queue of 1 is not practical, as soon as you have an element, you cannot push elements unless you have a consumer. Ofcourse, this can be done with bounded_push.
If it's okay for you. I would separate deprecation into a different PR as this is not the main intention of this PR. Once we have it cleanly integrated with ros2_controllers, then we can cleanly deprecate it. What do you think? |
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 tested that with ros-controls/ros2_controllers#1480, the API works for me!
@christophfroehlich I had to rewrite some parts of tests to reuse rather than copying for every instance. I've add more tests for all constructable types |
Fixes #14