ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

ROS2: non-reentrant callbacks, ignored callbacks

asked 2018-11-12 03:56:04 -0500

uthinu gravatar image

updated 2018-11-12 06:29:54 -0500

Hi, I use MultiThreadExecutor. I make a subscriber callback wait and it seems that while it happens any further calls of this exact callback are silently ignored until the first one returns? Is it really so? If yes, can it be changed?

It might be a fine default, but otherwise, even if a callback method returns shortly, such a behaviour may lead to occasional losses, glitches, whatever (scheduling grain, unexpectedly long preemption, high frequency dispatch, to name a few causes). Any mechanism of assuring a 100% reception?

I have seen a Python example with ReentrantCallbackGroup, but find . -iname "*Reentrant*" on my copy of ROS2 source tree yields nothing. I have found rclcpp::callback_group::CallbackGroupType::Reentrant, but I wonder, should each timer/subscriber have its own group like that in order to be independent, or can can several of them share such a group and still be mutually inclusive?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2018-11-12 06:31:41 -0500

uthinu gravatar image

updated 2018-11-12 14:26:21 -0500

According to this, reentrant mutually inclusive callbacks should be put into either separate or common reentrant groups, it changes nothing. Please correct me if I am wrong.

edit flag offensive delete link more

Comments

I think you mean reentract -> reentrant and mutually inclusive -> mutually exclusive.

William gravatar image William  ( 2018-11-12 11:48:14 -0500 )edit
1

You are right, however, that having one or many reentrant groups doesn't matter. I would advise putting a callback which you want to be called concurrently into a reentrant callback group. Note, however, that in this case you need to synchronize access to shared resources.

William gravatar image William  ( 2018-11-12 11:49:51 -0500 )edit

@William I meant mutually inclusive for CallbackGroupType::Reentrant, mutually exclusive would be for CallbackGroupType::MutuallyExclusive. Am I right?

uthinu gravatar image uthinu  ( 2018-11-12 14:28:26 -0500 )edit

Sorry, I call the opposite of "mutually exclusive" "reentrant". "Mutually inclusive" isn't mentioned anywhere in the code, and while in plain english it might be the opposite, in this case I don't think the term makes sense. If I were to pick an alternative to "reentrant" I'd use "concurrent".

William gravatar image William  ( 2018-11-12 14:35:12 -0500 )edit

@William Possibly you are right. For me, reentrant is one object, e.g. a single callback. By "mutually inclusive" I meant that more that one (already reentrant) callback in a group ::Reentrant can be called at once. Is it true?

uthinu gravatar image uthinu  ( 2018-11-12 14:47:31 -0500 )edit

I think there's a language barrier here, because we are speaking about a single callback here. If you have more than one callback defined (e.g. one for laser and one for imu) then they just need to be in separate callback groups, the type doesn't matter.

William gravatar image William  ( 2018-11-12 15:34:14 -0500 )edit

I meant that more that one (already reentrant) callback in a group ::Reentrant can be called at once. Is it true?

It is also true that more than one callback in a reentrant callback group lets the two callbacks be called concurrently with each other as well as with themselves.

William gravatar image William  ( 2018-11-12 15:35:31 -0500 )edit

Thanks William!

uthinu gravatar image uthinu  ( 2018-11-12 15:40:14 -0500 )edit

Question Tools

2 followers

Stats

Asked: 2018-11-12 03:56:04 -0500

Seen: 1,009 times

Last updated: Nov 12 '18