[ros-users] Nodelets and thread safety

[Tully Foote]

Hi Daniel,

In the image pipeline every new image is allocated once and passed on. To
mutate it at an intermediate step it must be copied and mutated (these can
be combined often).  If you add the locks as suggested and wait for the
subscriber to finish using the message,  single subscriber doing a long
running operation can stop a source from publishing completely by holding
onto the lock for the message.  Thereby blocking sending to all potential
subscribers indefinitely.

The roscpp direct memory transports have restrictions.  All callbacks which
don't automatically provide an dedicated copy use a const pointers so you
cannot mutate the data received. And the publisher has a responsibility to
not mutate the data structure after publish when publishing using a shared
pointer.
http://www.ros.org/doc/api/roscpp/html/classros_1_1Publisher.html#a16b7602d82ef89dff56a92cc7dc3d7cd

These restrictions are in place to allow the anonymous publish subscribe
abstraction to remain consistent across all implementations.  In anonymous
publish subscribe you do not know what else is listening or sending on any
topic.  For example if you happen to run "rostopic echo /my_topic" or
"rostopic pub /my_topic 123" all of a sudden any reliance on the pointer or
a mutex being consistent is broken, for if it comes in over the wire the
receivers will get different copies.  Also if a different nodelet is spun up
to debug the incoming topic and it stores the incoming messages to generate
an aggregate output, its output will be corrupted by changing the content of
the received message in a different nodelet.  And as above if this nodelet
locked the message you lock the upstream publisher and no more messages
arrive.

Taking away these restrictions you can do whatever you want, but you are no
longer an anonymous publish subscribe ROS transport.  And ROS debugging and
introspection tools cannot work in all cases.

If these restrictions are too restrictive sharing memory can be done many
ways, more generally than the roscpp transport.  If you want to make the
parts dynamically loadable, I would suggest that you at pluginlib, where you
can build your arbitrary memory sharing ability into the baseclass for your
plugin.  However in doing a custom system you will lose the general ROS
connectivity, debugging, and introspection.

Tully

On Sat, Oct 23, 2010 at 6:32 PM, Daniel Stonier <d.stonier at gmail.com> wrote:

>
>
> On 24 October 2010 08:15, Josh Faust <jfaust at willowgarage.com> wrote:
>
>> A couple of the guys here at work were talking about passing around large
>>> objects with the nodelets when we realised there was no thread safety
>>> attached to the objects that were getting passed around. Is there any plans
>>> to add this functionality to them? i.e. either via something like a
>>> Mutex.msg you could include with your other msg's (aka Time.msg) or perhaps
>>> via a thread safe shared pointer that you could use when publishing.
>>>
>>
>> I'm not really sure what you mean -- boost::shared_ptr is atomically
>> reference counted, so it the object won't be deleted out from under you if
>> you have multiple subscribers to the same topic.  If you need to modify the
>> object in the subscriber you can subscribe to a non-const version of the
>> message, and it will make a copy for you if there are multiple subscribers.
>>  Do you mean you want to be able to modify the object on the publisher side
>> after you've sent it?
>>
>> Josh
>>
>
> Yes, exactly. i.e. sharing a large object between publisher and
> subscriber(s) and you want to avoid any copying or recreation of the object.
> The publisher is continually updating the large object and the subscribers
> don't want to get caught by an update in the middle of reading. Is there
> perhaps a better approach to this? How do the guys in the image pipeline
> handle the sending of big objects - they simply recreate a new object every
> time they want to send one?
>
>
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>
>
> --
> Phone : +82-10-5400-3296 (010-5400-3296)
> Home: http://snorriheim.dnsdojo.com/
> Yujin Robot: http://www.yujinrobot.com/
> Embedded Ros : http://www.ros.org/wiki/eros
> Embedded Control Libraries: http://snorriheim.dnsdojo.com/redmine/wiki/ecl
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>


-- 
Tully Foote
Systems Engineer
Willow Garage, Inc.
tfoote at willowgarage.com
(650) 475-2827
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101024/23004c22/attachment-0003.html>