Re: Limitations with v2 port implementation

On Wed, Apr 8, 2015 at 3:32 PM, S Roderick <[email protected]> wrote:

> On Apr 08, 2015, at 09:25, Ruben Smits <[email protected]>
> wrote:
>
>
>
> On Wed, Apr 8, 2015 at 1:08 PM, S Roderick <[email protected]> wrote:
>
>> We have ported a large Orocos system from v1 to v2, and identified some
>> limitations in the v2 port implementation that we wanted to discuss with
>> the community.
>>
>> v1 ports essentially had one connection object, and thus one value. When
>> you connected/read the port, you got the last value that was written. There
>> was no concept of “flow” (i.e. when a connection object was updated).
>>
>> v2 ports have one “object" per input/output connection, and maintain
>> potentially different values and flow status per connection (yes, I’m
>> simplifying here). So one output port connected to N input ports will have
>> N connections, each with potentially different values and flow status.
>>
>> We’ve run into two issues with v2 ports:
>>
>> 1) performance when writing to output ports is much slower in v2 than v1,
>> as essentially the update occurs to multiple connection objects in v2 (in
>> v1 it occurred to one connection object). One of our components has a 450%
>> slow down when writing to its eight (8) output ports.
>>
>> 2) flow status does not cover the use case where you want a single
>> connection object, and don’t care when a connection is made nor when a
>> value is written (i.e. you don’t care about “flow”). One of our examples
>> here is static configuration data (say the name, model or serial number, of
>> a device, or a robot’s number of DOF). When the source component is
>> configured or started, it writes the appropriate data to the port. If a
>> connection is made in the future (say by a GUI, or by a reporting component
>> that has dynamically created ports) then v2 ports will not present the
>> value that was previously written (I believe as there has been no “flow” of
>> data since the connection was made). In this use case, we believe that the
>> v1 single-connection-object semantics made more sense as connected peer
>> components are only interested in the value, and not when it was written
>> nor whether it has been updated (i.e. they don’t care about flow).
>>
>
> AFAIK, you can have 2) working in v2 if you create the connection using
> the init flag set to true:
> http://www.orocos.org/stable/documentation/rtt/v2.x/api/html/classRTT_1_1ConnPolicy.html#a5da839ba68d6ff35ddc44171562ed356
>  and a have a writer with keepLastWrittenValue to true.
>
>
> I don’t think that that solves the whole issue. You still have multiple
> connections => performance hit. Also, didn’t we find a thread-safety issue
> with that approach?
>

You would still have the performance hit, but AFAIR the thread-safety issue
only exists if you have multiple writers, which probably does not match the
static configuration data use-case? Nevertheless, you are right, one can
perfectly imagine a use-case where it would be a problem.

R.


> S
>
>
> R.
>
>
>>
>> We are *not* saying that the v2 flow status port implementation is bad,
>> wrong or incorrect, We're simply saying that it doesn’t deal with some
>> valid use cases. The question is, what does the community think, and what
>> should be done about it?
>>
>> Cheers
>> Stephen
>>
>
>


-- 
Ruben Smits, Roboticist - Founder
+32 479 511 786
Intermodalics - Kapeldreef 60, 3001 Heverlee - BELGIUM
www.intermodalics.eu

-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev