 Orocos Real-Time ToolkitSmarter realtime. Safer threads
|
|
DataPort threadsafe for incrmentes
Consider this (pseudo) code: DataPort<int> data; Is it thread-safe? In my opinion this operation of increment is not. data.Increment( x ) To perform operations like that Davide DataPort threadsafe for incrmentesSubmitted by bruyninc on Thu, 2009-05-21 15:00.
On Thu, 21 May 2009, Davide Faconti wrote: > Consider this (pseudo) code: Thread-safety is all about keeping your data consistent, that is, doing > I suggest therefore to include in RTT 2.0 the function This would not solve your problem! The two (or more) threads accessing the This is not a "bug" but a fact of life of distributed, component-based Herman |
DataPort threadsafe for incrmentes
On Thu, May 21, 2009 at 16:37, Davide Faconti <faconti [..] ...> wrote:
> Consider this (pseudo) code:
>
> DataPort<int> data;
> ...
> int current_value = data.Get();
> current_value++;
> data.Set( current_value );
>
> Is it thread-safe? In my opinion this operation of increment is not.
> I suggest therefore to include in RTT 2.0 the function
>
> data.Increment( x )
>
> To perform operations like that
I'm not a fan either. First of all, Sylvain actually dropped support
for Input+Output ports
So you'd be required to read from one port and write into an other. I
believe it is intentionally
to prevent the above scenario's which are indeed not reliable.
Are you using data ports for resource counting/management ? Isn't this
the responsibility
of a component and hence belongs in a method interface, where you can make this
mechanism thread safe by simply using a mutex ?
Peter
DataPort threadsafe for incrmentes
On May 21, 2009, at 11:09 , Peter Soetens wrote:
> On Thu, May 21, 2009 at 16:37, Davide Faconti <faconti [..] ...
> > wrote:
>> Consider this (pseudo) code:
>>
>> DataPort<int> data;
>> ...
>> int current_value = data.Get();
>> current_value++;
>> data.Set( current_value );
>>
>> Is it thread-safe? In my opinion this operation of increment is not.
>> I suggest therefore to include in RTT 2.0 the function
>>
>> data.Increment( x )
>>
>> To perform operations like that
>
> I'm not a fan either. First of all, Sylvain actually dropped support
> for Input+Output ports
> So you'd be required to read from one port and write into an other. I
> believe it is intentionally
> to prevent the above scenario's which are indeed not reliable.
Really? No more DataPort's at some point in the future? When will this
hit ... yes I do remember a *very* long discussion about ports and
stuff a while back. Didn't realise this was coming out of it.
I presume that the current Cobra reliance on DataPort's, and not Read
or Write Ports, will be dealt with?
S
DataPort threadsafe for incrmentes
On Fri, May 22, 2009 at 02:53, S Roderick <kiwi [dot] net [..] ...> wrote:
>
> On May 21, 2009, at 11:09 , Peter Soetens wrote:
...
>> I'm not a fan either. First of all, Sylvain actually dropped support
>> for Input+Output ports
>> So you'd be required to read from one port and write into an other. I
>> believe it is intentionally
>> to prevent the above scenario's which are indeed not reliable.
>
> Really? No more DataPort's at some point in the future? When will this hit
> ... yes I do remember a *very* long discussion about ports and stuff a while
> back. Didn't realise this was coming out of it.
Not at all !
In RTT 1.x speak: ReadDataPort<T>, WriteDataPort<T> remain, DataPort<T>
goes away.
In RTT 2.x speak this means: only InputPort<T> and OutputPort<T>.
Concerning buffers, this policy is set at connection time, so
ReadBufferPort, WriteBufferPort
and BufferPort are replaced by the above and the fact of using a
buffer (or not) is set when
you connect the components.
Will be documented in API and manuals when it comes this far...
Peter
DataPort threadsafe for incrmentes
On Thu, May 21, 2009 at 08:53:21PM -0400, S Roderick wrote:
>
> On May 21, 2009, at 11:09 , Peter Soetens wrote:
> > On Thu, May 21, 2009 at 16:37, Davide Faconti <faconti [..] ...
> > > wrote:
> >> Consider this (pseudo) code:
> >>
> >> DataPort<int> data;
> >> ...
> >> int current_value = data.Get();
> >> current_value++;
> >> data.Set( current_value );
> >>
> >> Is it thread-safe? In my opinion this operation of increment is not.
> >> I suggest therefore to include in RTT 2.0 the function
> >>
> >> data.Increment( x )
> >>
> >> To perform operations like that
> >
> > I'm not a fan either. First of all, Sylvain actually dropped support
> > for Input+Output ports
> > So you'd be required to read from one port and write into an other. I
> > believe it is intentionally
> > to prevent the above scenario's which are indeed not reliable.
>
> Really? No more DataPort's at some point in the future? When will this
No! Only ReadWrite dataports are going, not data ports in general!
Markus
DataPort threadsafe for incrmentes
On Fri, 22 May 2009, Markus Klotzb???cher wrote:
>> On May 21, 2009, at 11:09 , Peter Soetens wrote:
>>> On Thu, May 21, 2009 at 16:37, Davide Faconti <faconti [..] ...
>>>> wrote:
>>>> Consider this (pseudo) code:
>>>>
>>>> DataPort<int> data;
>>>> ...
>>>> int current_value = data.Get();
>>>> current_value++;
>>>> data.Set( current_value );
>>>>
>>>> Is it thread-safe? In my opinion this operation of increment is not.
>>>> I suggest therefore to include in RTT 2.0 the function
>>>>
>>>> data.Increment( x )
>>>>
>>>> To perform operations like that
>>>
>>> I'm not a fan either. First of all, Sylvain actually dropped support
>>> for Input+Output ports
>>> So you'd be required to read from one port and write into an other. I
>>> believe it is intentionally
>>> to prevent the above scenario's which are indeed not reliable.
>>
>> Really? No more DataPort's at some point in the future? When will this
>
> No! Only ReadWrite dataports are going, not data ports in general!
>
Good. (At least, I think so.) ReadWrite dataports should not be an RTT
primitive, but should be an _architectural_ decision in your application,
in the sense that they represent the simplest(?) example of the the more
general concept of a "data component", that is, a component that is
responsible for all operations on a particular set of data, including
reading and writing from client components.
Herman
DataPort threadsafe for incrmentes
On Fri, May 22, 2009 at 01:52:17PM +0200, Herman Bruyninckx wrote:
> On Fri, 22 May 2009, Markus Klotzb???cher wrote:
> >> On May 21, 2009, at 11:09 , Peter Soetens wrote:
> >>> On Thu, May 21, 2009 at 16:37, Davide Faconti <faconti [..] ...
> >>>> wrote:
> >>>> Consider this (pseudo) code:
> >>>>
> >>>> DataPort<int> data;
> >>>> ...
> >>>> int current_value = data.Get();
> >>>> current_value++;
> >>>> data.Set( current_value );
> >>>>
> >>>> Is it thread-safe? In my opinion this operation of increment is not.
> >>>> I suggest therefore to include in RTT 2.0 the function
> >>>>
> >>>> data.Increment( x )
> >>>>
> >>>> To perform operations like that
> >>>
> >>> I'm not a fan either. First of all, Sylvain actually dropped support
> >>> for Input+Output ports
> >>> So you'd be required to read from one port and write into an other. I
> >>> believe it is intentionally
> >>> to prevent the above scenario's which are indeed not reliable.
> >>
> >> Really? No more DataPort's at some point in the future? When will this
> >
> > No! Only ReadWrite dataports are going, not data ports in general!
> >
> Good. (At least, I think so.) ReadWrite dataports should not be an RTT
> primitive, but should be an _architectural_ decision in your application,
> in the sense that they represent the simplest(?) example of the the more
> general concept of a "data component", that is, a component that is
> responsible for all operations on a particular set of data, including
> reading and writing from client components.
Good point. What about the buffered ports? Wouldn't these too be
better expressed as components with configurable types (lock-free,
etc) and configurable capacities?
This quickly leads to the idea of composite components, which I think
would be nice and important - but unfortunately not very easy.
Markus
DataPort threadsafe for incrmentes
On Sun, May 24, 2009 at 15:29, Markus Klotzbücher
<markus [dot] klotzbuecher [..] ...> wrote:
> On Fri, May 22, 2009 at 01:52:17PM +0200, Herman Bruyninckx wrote:
>> On Fri, 22 May 2009, Markus Klotzb???cher wrote:
>> >> On May 21, 2009, at 11:09 , Peter Soetens wrote:
>> >>> On Thu, May 21, 2009 at 16:37, Davide Faconti <faconti [..] ...
>> >>>> wrote:
>> >>>> Consider this (pseudo) code:
>> >>>>
>> >>>> DataPort<int> data;
>> >>>> ...
>> >>>> int current_value = data.Get();
>> >>>> current_value++;
>> >>>> data.Set( current_value );
>> >>>>
>> >>>> Is it thread-safe? In my opinion this operation of increment is not.
>> >>>> I suggest therefore to include in RTT 2.0 the function
>> >>>>
>> >>>> data.Increment( x )
>> >>>>
>> >>>> To perform operations like that
>> >>>
>> >>> I'm not a fan either. First of all, Sylvain actually dropped support
>> >>> for Input+Output ports
>> >>> So you'd be required to read from one port and write into an other. I
>> >>> believe it is intentionally
>> >>> to prevent the above scenario's which are indeed not reliable.
>> >>
>> >> Really? No more DataPort's at some point in the future? When will this
>> >
>> > No! Only ReadWrite dataports are going, not data ports in general!
>> >
>> Good. (At least, I think so.) ReadWrite dataports should not be an RTT
>> primitive, but should be an _architectural_ decision in your application,
>> in the sense that they represent the simplest(?) example of the the more
>> general concept of a "data component", that is, a component that is
>> responsible for all operations on a particular set of data, including
>> reading and writing from client components.
>
> Good point. What about the buffered ports? Wouldn't these too be
> better expressed as components with configurable types (lock-free,
> etc) and configurable capacities?
Where is this going ? I don't think anyone was suggesting that ports
should become components ? The port is where the user-code connects
with the middleware. It's an abstraction point. The middleware does allow
all kinds of data transportation policies, implemented by objects,
but these are by no means components. They are libraries.
>
> This quickly leads to the idea of composite components, which I think
> would be nice and important - but unfortunately not very easy.
Composition is done by port forwarding iirc. I don't see the logic behind
all this reasoning...
Peter
DataPort threadsafe for incrmentes
On Mon, May 25, 2009 at 02:21:34PM +0200, Peter Soetens wrote:
> On Sun, May 24, 2009 at 15:29, Markus Klotzbücher
> <markus [dot] klotzbuecher [..] ...> wrote:
> > On Fri, May 22, 2009 at 01:52:17PM +0200, Herman Bruyninckx wrote:
> >> On Fri, 22 May 2009, Markus Klotzb???cher wrote:
> >> >> On May 21, 2009, at 11:09 , Peter Soetens wrote:
> >> >>> On Thu, May 21, 2009 at 16:37, Davide Faconti <faconti [..] ...
> >> >>>> wrote:
> >> >>>> Consider this (pseudo) code:
> >> >>>>
> >> >>>> DataPort<int> data;
> >> >>>> ...
> >> >>>> int current_value = data.Get();
> >> >>>> current_value++;
> >> >>>> data.Set( current_value );
> >> >>>>
> >> >>>> Is it thread-safe? In my opinion this operation of increment is not.
> >> >>>> I suggest therefore to include in RTT 2.0 the function
> >> >>>>
> >> >>>> data.Increment( x )
> >> >>>>
> >> >>>> To perform operations like that
> >> >>>
> >> >>> I'm not a fan either. First of all, Sylvain actually dropped support
> >> >>> for Input+Output ports
> >> >>> So you'd be required to read from one port and write into an other. I
> >> >>> believe it is intentionally
> >> >>> to prevent the above scenario's which are indeed not reliable.
> >> >>
> >> >> Really? No more DataPort's at some point in the future? When will this
> >> >
> >> > No! Only ReadWrite dataports are going, not data ports in general!
> >> >
> >> Good. (At least, I think so.) ReadWrite dataports should not be an RTT
> >> primitive, but should be an _architectural_ decision in your application,
> >> in the sense that they represent the simplest(?) example of the the more
> >> general concept of a "data component", that is, a component that is
> >> responsible for all operations on a particular set of data, including
> >> reading and writing from client components.
> >
> > Good point. What about the buffered ports? Wouldn't these too be
> > better expressed as components with configurable types (lock-free,
> > etc) and configurable capacities?
>
> Where is this going ? I don't think anyone was suggesting that ports
> should become components ? The port is where the user-code connects
> with the middleware. It's an abstraction point. The middleware does allow
> all kinds of data transportation policies, implemented by objects,
> but these are by no means components. They are libraries.
I agree with all you say, but libraries have their limits when it
comes to doing dynamic things such as changing things on the fly.
I'm not saying turn all ports into components. I'm just suggesting
that some more complex/exotic port types might be better implemented
as components.
> > This quickly leads to the idea of composite components, which I think
> > would be nice and important - but unfortunately not very easy.
>
> Composition is done by port forwarding iirc. I don't see the logic behind
> all this reasoning...
If I wrote a component that uses such a Port-as-Component to offer
data then it would be part of my (then composite) component.
I think composition is something important to keep in mind, but
probably more a 3.0 item...
Markus
DataPort threadsafe for incrmentes
On Mon, May 25, 2009 at 17:30, Markus Klotzbuecher
<markus [dot] klotzbuecher [..] ...> wrote:
> On Mon, May 25, 2009 at 02:21:34PM +0200, Peter Soetens wrote:
>> On Sun, May 24, 2009 at 15:29, Markus Klotzbücher
>> <markus [dot] klotzbuecher [..] ...> wrote:
>> > On Fri, May 22, 2009 at 01:52:17PM +0200, Herman Bruyninckx wrote:
>> >> On Fri, 22 May 2009, Markus Klotzb???cher wrote:
>> >> >> On May 21, 2009, at 11:09 , Peter Soetens wrote:
>> >> >>> On Thu, May 21, 2009 at 16:37, Davide Faconti <faconti [..] ...
>> >> >>>> wrote:
>> >> >>>> Consider this (pseudo) code:
>> >> >>>>
>> >> >>>> DataPort<int> data;
>> >> >>>> ...
>> >> >>>> int current_value = data.Get();
>> >> >>>> current_value++;
>> >> >>>> data.Set( current_value );
>> >> >>>>
>> >> >>>> Is it thread-safe? In my opinion this operation of increment is not.
>> >> >>>> I suggest therefore to include in RTT 2.0 the function
>> >> >>>>
>> >> >>>> data.Increment( x )
>> >> >>>>
>> >> >>>> To perform operations like that
>> >> >>>
>> >> >>> I'm not a fan either. First of all, Sylvain actually dropped support
>> >> >>> for Input+Output ports
>> >> >>> So you'd be required to read from one port and write into an other. I
>> >> >>> believe it is intentionally
>> >> >>> to prevent the above scenario's which are indeed not reliable.
>> >> >>
>> >> >> Really? No more DataPort's at some point in the future? When will this
>> >> >
>> >> > No! Only ReadWrite dataports are going, not data ports in general!
>> >> >
>> >> Good. (At least, I think so.) ReadWrite dataports should not be an RTT
>> >> primitive, but should be an _architectural_ decision in your application,
>> >> in the sense that they represent the simplest(?) example of the the more
>> >> general concept of a "data component", that is, a component that is
>> >> responsible for all operations on a particular set of data, including
>> >> reading and writing from client components.
>> >
>> > Good point. What about the buffered ports? Wouldn't these too be
>> > better expressed as components with configurable types (lock-free,
>> > etc) and configurable capacities?
>>
>> Where is this going ? I don't think anyone was suggesting that ports
>> should become components ? The port is where the user-code connects
>> with the middleware. It's an abstraction point. The middleware does allow
>> all kinds of data transportation policies, implemented by objects,
>> but these are by no means components. They are libraries.
>
> I agree with all you say, but libraries have their limits when it
> comes to doing dynamic things such as changing things on the fly.
How's that ? The RTT defines the interface a given port policy (ie
implementation)
must respect. Each object that satisfies this interface can be used during
deployment to setup a connection between on or more data ports, 'on the fly'.
The only case up till now where we agreed on having components manage
data flow is when data should be 'routed' to components instead of broadcasted.
But even in that case, normal ports remain in there to abstract the connections
between components.
>
> I'm not saying turn all ports into components. I'm just suggesting
> that some more complex/exotic port types might be better implemented
> as components.
But you could agree that these components use 'standard' ports in turn to
accomplish their complex behaviour ?
>
>> > This quickly leads to the idea of composite components, which I think
>> > would be nice and important - but unfortunately not very easy.
>>
>> Composition is done by port forwarding iirc. I don't see the logic behind
>> all this reasoning...
>
> If I wrote a component that uses such a Port-as-Component to offer
> data then it would be part of my (then composite) component.
>
> I think composition is something important to keep in mind, but
> probably more a 3.0 item...
I'd rather see it as a 2.x item.
Peter
DataPort threadsafe for incrmentes
On Mon, May 25, 2009 at 09:37:06PM +0200, Peter Soetens wrote:
> On Mon, May 25, 2009 at 17:30, Markus Klotzbuecher
> <markus [dot] klotzbuecher [..] ...> wrote:
> > On Mon, May 25, 2009 at 02:21:34PM +0200, Peter Soetens wrote:
> >> On Sun, May 24, 2009 at 15:29, Markus Klotzbücher
> >> <markus [dot] klotzbuecher [..] ...> wrote:
> >> > On Fri, May 22, 2009 at 01:52:17PM +0200, Herman Bruyninckx wrote:
> >> >> On Fri, 22 May 2009, Markus Klotzb???cher wrote:
> >> >> >> On May 21, 2009, at 11:09 , Peter Soetens wrote:
> >> >> >>> On Thu, May 21, 2009 at 16:37, Davide Faconti <faconti [..] ...
> >> >> >>>> wrote:
> >> >> >>>> Consider this (pseudo) code:
> >> >> >>>>
> >> >> >>>> DataPort<int> data;
> >> >> >>>> ...
> >> >> >>>> int current_value = data.Get();
> >> >> >>>> current_value++;
> >> >> >>>> data.Set( current_value );
> >> >> >>>>
> >> >> >>>> Is it thread-safe? In my opinion this operation of increment is not.
> >> >> >>>> I suggest therefore to include in RTT 2.0 the function
> >> >> >>>>
> >> >> >>>> data.Increment( x )
> >> >> >>>>
> >> >> >>>> To perform operations like that
> >> >> >>>
> >> >> >>> I'm not a fan either. First of all, Sylvain actually dropped support
> >> >> >>> for Input+Output ports
> >> >> >>> So you'd be required to read from one port and write into an other. I
> >> >> >>> believe it is intentionally
> >> >> >>> to prevent the above scenario's which are indeed not reliable.
> >> >> >>
> >> >> >> Really? No more DataPort's at some point in the future? When will this
> >> >> >
> >> >> > No! Only ReadWrite dataports are going, not data ports in general!
> >> >> >
> >> >> Good. (At least, I think so.) ReadWrite dataports should not be an RTT
> >> >> primitive, but should be an _architectural_ decision in your application,
> >> >> in the sense that they represent the simplest(?) example of the the more
> >> >> general concept of a "data component", that is, a component that is
> >> >> responsible for all operations on a particular set of data, including
> >> >> reading and writing from client components.
> >> >
> >> > Good point. What about the buffered ports? Wouldn't these too be
> >> > better expressed as components with configurable types (lock-free,
> >> > etc) and configurable capacities?
> >>
> >> Where is this going ? I don't think anyone was suggesting that ports
> >> should become components ? The port is where the user-code connects
> >> with the middleware. It's an abstraction point. The middleware does allow
> >> all kinds of data transportation policies, implemented by objects,
> >> but these are by no means components. They are libraries.
> >
> > I agree with all you say, but libraries have their limits when it
> > comes to doing dynamic things such as changing things on the fly.
>
> How's that ? The RTT defines the interface a given port policy (ie
> implementation)
> must respect. Each object that satisfies this interface can be used during
> deployment to setup a connection between on or more data ports, 'on the fly'.
But this interface is bound to grow when new useful policies are
found... OTOH wouldn't it be natural to configure the buffer size or
the overrun policy etc. as RTT::Properties and be notified by an
RTT::Event one subscribed to when things go wrong?
> The only case up till now where we agreed on having components manage
> data flow is when data should be 'routed' to components instead of broadcasted.
> But even in that case, normal ports remain in there to abstract the connections
> between components.
>
> >
> > I'm not saying turn all ports into components. I'm just suggesting
> > that some more complex/exotic port types might be better implemented
> > as components.
>
> But you could agree that these components use 'standard' ports in turn to
> accomplish their complex behaviour ?
Yes of course! I'm only suggesting that the policies of primitves
should be reduced to the absolut minimum necessary and that more
complex ports should be constructable from these (possibly as
components).
> >> > This quickly leads to the idea of composite components, which I think
> >> > would be nice and important - but unfortunately not very easy.
> >>
> >> Composition is done by port forwarding iirc. I don't see the logic behind
> >> all this reasoning...
> >
> > If I wrote a component that uses such a Port-as-Component to offer
> > data then it would be part of my (then composite) component.
> >
> > I think composition is something important to keep in mind, but
> > probably more a 3.0 item...
>
> I'd rather see it as a 2.x item.
Even better!
Markus
Re: DataPort threadsafe for incrmentes
On Mon, May 25, 2009 at 09:37:06PM +0200, Peter Soetens wrote:
> >
> > I think composition is something important to keep in mind, but
> > probably more a 3.0 item...
>
> I'd rather see it as a 2.x item.
Even better!
Markus
The discussion has drifted away from the original topic, yet it is interesting and important, so what the heck.
As mentioned previously, I have implemented my own version of composite components, as an extension of RTT 1.8. For this purpose, I have subclassed ReadDataPort with my InputPort class and WriteDataPort with OutputPort. I had some discussion with Sylvian and expect that it will not be too hard to switch to 2.0 ports.
I will discuss internally if I can make my work public. I'm not sure if it meets your standards, however, it might be interesting, that's up to you. I'll be back..
Regards, Theo.
DataPort threadsafe for incrmentes
On Mon, 25 May 2009, Peter Soetens wrote:
> On Sun, May 24, 2009 at 15:29, Markus Klotzbücher
> <markus [dot] klotzbuecher [..] ...> wrote:
>> On Fri, May 22, 2009 at 01:52:17PM +0200, Herman Bruyninckx wrote:
>>> On Fri, 22 May 2009, Markus Klotzb???cher wrote:
>>>>> On May 21, 2009, at 11:09 , Peter Soetens wrote:
>>>>>> On Thu, May 21, 2009 at 16:37, Davide Faconti <faconti [..] ...
>>>>>>> wrote:
>>>>>>> Consider this (pseudo) code:
>>>>>>>
>>>>>>> DataPort<int> data;
>>>>>>> ...
>>>>>>> int current_value = data.Get();
>>>>>>> current_value++;
>>>>>>> data.Set( current_value );
>>>>>>>
>>>>>>> Is it thread-safe? In my opinion this operation of increment is not.
>>>>>>> I suggest therefore to include in RTT 2.0 the function
>>>>>>>
>>>>>>> data.Increment( x )
>>>>>>>
>>>>>>> To perform operations like that
>>>>>>
>>>>>> I'm not a fan either. First of all, Sylvain actually dropped support
>>>>>> for Input+Output ports
>>>>>> So you'd be required to read from one port and write into an other. I
>>>>>> believe it is intentionally
>>>>>> to prevent the above scenario's which are indeed not reliable.
>>>>>
>>>>> Really? No more DataPort's at some point in the future? When will this
>>>>
>>>> No! Only ReadWrite dataports are going, not data ports in general!
>>>>
>>> Good. (At least, I think so.) ReadWrite dataports should not be an RTT
>>> primitive, but should be an _architectural_ decision in your application,
>>> in the sense that they represent the simplest(?) example of the the more
>>> general concept of a "data component", that is, a component that is
>>> responsible for all operations on a particular set of data, including
>>> reading and writing from client components.
>>
>> Good point. What about the buffered ports? Wouldn't these too be
>> better expressed as components with configurable types (lock-free,
>> etc) and configurable capacities?
>
> Where is this going ? I don't think anyone was suggesting that ports
> should become components ? The port is where the user-code connects
> with the middleware. It's an abstraction point. The middleware does allow
> all kinds of data transportation policies, implemented by objects,
> but these are by no means components. They are libraries.
>
They _could_ be components! (As is the case with any library that requires
its own activity, just to mention one possible use case...) In robotics,
the most obvious example is the 'world model': in every application,
various (distributed) components require to access (write, read) data
to/from a worldmodel, and keeping the world model consistent while serving
different "clients" requires component-features...
>> This quickly leads to the idea of composite components, which I think
>> would be nice and important - but unfortunately not very easy.
>
> Composition is done by port forwarding iirc. I don't see the logic behind
> all this reasoning...
The logic is in the _scaling_: making larger and larger interconnections of
data ports requires, sooner or later, a (component-based)
"supervision"/"Coordination" of the interconnections as well as of the
contents of the data and the 'services' delivered to all clients.
Herman
DataPort threadsafe for incrmentes
>> Good. (At least, I think so.) ReadWrite dataports should not be an RTT
>> primitive, but should be an _architectural_ decision in your application,
>> in the sense that they represent the simplest(?) example of the the more
>> general concept of a "data component", that is, a component that is
>> responsible for all operations on a particular set of data, including
>> reading and writing from client components.
>>
>
> Good point. What about the buffered ports? Wouldn't these too be
> better expressed as components with configurable types (lock-free,
> etc) and configurable capacities?
>
I think this is not at all related. As I get it, the idea behind "data
components" is to have components that manage a set of data, with input
ports to get updates from outside (like new data readings) and output
ports to send updates to interested components.
"Buffered" components make no sense there. You have buffer connections,
that are set up at deployment time of course (with lock-free or so
specified there as well). But I don't see the point having them as
components.
> This quickly leads to the idea of composite components, which I think
> would be nice and important - but unfortunately not very easy.
>
As for having composite components, my port implementation does not
support those. I think that would be doable, but still needs a bit of
thinking.
--
Sylvain Joyeux
Forschunggruppe Robotik - Space and Security
DFKI Bremen
Robert-Hooke-Straße 5
28359 Bremen, Germany
Phone: +49 (0)421 218-641xx
Fax: +49 (0)421 218-641xx
E-Mail: vorname [dot] name [..] ...
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
DataPort threadsafe for incrmentes
On Mon, 25 May 2009, Sylvain Joyeux wrote:
>
>>> Good. (At least, I think so.) ReadWrite dataports should not be an RTT
>>> primitive, but should be an _architectural_ decision in your application,
>>> in the sense that they represent the simplest(?) example of the the more
>>> general concept of a "data component", that is, a component that is
>>> responsible for all operations on a particular set of data, including
>>> reading and writing from client components.
>>>
>>
>> Good point. What about the buffered ports? Wouldn't these too be
>> better expressed as components with configurable types (lock-free,
>> etc) and configurable capacities?
>>
> I think this is not at all related. As I get it, the idea behind "data
> components" is to have components that manage a set of data, with input
> ports to get updates from outside (like new data readings) and output
> ports to send updates to interested components.
>
> "Buffered" components make no sense there. You have buffer connections,
> that are set up at deployment time of course (with lock-free or so
> specified there as well). But I don't see the point having them as
> components.
I do... What do you do when you have different clients for the same data,
each with a possibly different "buffering" QoS?
>> This quickly leads to the idea of composite components, which I think
>> would be nice and important - but unfortunately not very easy.
>>
> As for having composite components, my port implementation does not
> support those. I think that would be doable, but still needs a bit of
> thinking.
I would keep the composition aspects separate from the data flow aspects...
Composition is for components.
Herman
DataPort threadsafe for incrmentes
Herman Bruyninckx wrote:
> On Mon, 25 May 2009, Sylvain Joyeux wrote:
>
>
>>>> Good. (At least, I think so.) ReadWrite dataports should not be an RTT
>>>> primitive, but should be an _architectural_ decision in your application,
>>>> in the sense that they represent the simplest(?) example of the the more
>>>> general concept of a "data component", that is, a component that is
>>>> responsible for all operations on a particular set of data, including
>>>> reading and writing from client components.
>>>>
>>>>
>>> Good point. What about the buffered ports? Wouldn't these too be
>>> better expressed as components with configurable types (lock-free,
>>> etc) and configurable capacities?
>>>
>>>
>> I think this is not at all related. As I get it, the idea behind "data
>> components" is to have components that manage a set of data, with input
>> ports to get updates from outside (like new data readings) and output
>> ports to send updates to interested components.
>>
>> "Buffered" components make no sense there. You have buffer connections,
>> that are set up at deployment time of course (with lock-free or so
>> specified there as well). But I don't see the point having them as
>> components.
>>
>
> I do... What do you do when you have different clients for the same data,
> each with a possibly different "buffering" QoS?
>
You create two different connections with two different policies from
the same output port.
DataPort threadsafe for incrmentes
On Mon, May 25, 2009 at 04:25:33PM +0200, Sylvain Joyeux wrote:
> Herman Bruyninckx wrote:
> > On Mon, 25 May 2009, Sylvain Joyeux wrote:
> >
> >
> >>>> Good. (At least, I think so.) ReadWrite dataports should not be an RTT
> >>>> primitive, but should be an _architectural_ decision in your application,
> >>>> in the sense that they represent the simplest(?) example of the the more
> >>>> general concept of a "data component", that is, a component that is
> >>>> responsible for all operations on a particular set of data, including
> >>>> reading and writing from client components.
> >>>>
> >>>>
> >>> Good point. What about the buffered ports? Wouldn't these too be
> >>> better expressed as components with configurable types (lock-free,
> >>> etc) and configurable capacities?
> >>>
> >>>
> >> I think this is not at all related. As I get it, the idea behind "data
> >> components" is to have components that manage a set of data, with input
> >> ports to get updates from outside (like new data readings) and output
> >> ports to send updates to interested components.
> >>
> >> "Buffered" components make no sense there. You have buffer connections,
> >> that are set up at deployment time of course (with lock-free or so
> >> specified there as well). But I don't see the point having them as
> >> components.
> >>
> >
> > I do... What do you do when you have different clients for the same data,
> > each with a possibly different "buffering" QoS?
> >
> You create two different connections with two different policies from
> the same output port.
Thats the point, primitives and policies do not go well
together. Especially if more and more policies are added. As
components these policies could move into OCL and keep the RTT lean.
Markus
DataPort threadsafe for incrmentes
On Sun, 24 May 2009, Markus Klotzb???cher wrote:
> On Fri, May 22, 2009 at 01:52:17PM +0200, Herman Bruyninckx wrote:
>> On Fri, 22 May 2009, Markus Klotzb???cher wrote:
>>>> On May 21, 2009, at 11:09 , Peter Soetens wrote:
>>>>> On Thu, May 21, 2009 at 16:37, Davide Faconti <faconti [..] ...
>>>>>> wrote:
>>>>>> Consider this (pseudo) code:
>>>>>>
>>>>>> DataPort<int> data;
>>>>>> ...
>>>>>> int current_value = data.Get();
>>>>>> current_value++;
>>>>>> data.Set( current_value );
>>>>>>
>>>>>> Is it thread-safe? In my opinion this operation of increment is not.
>>>>>> I suggest therefore to include in RTT 2.0 the function
>>>>>>
>>>>>> data.Increment( x )
>>>>>>
>>>>>> To perform operations like that
>>>>>
>>>>> I'm not a fan either. First of all, Sylvain actually dropped support
>>>>> for Input+Output ports
>>>>> So you'd be required to read from one port and write into an other. I
>>>>> believe it is intentionally
>>>>> to prevent the above scenario's which are indeed not reliable.
>>>>
>>>> Really? No more DataPort's at some point in the future? When will this
>>>
>>> No! Only ReadWrite dataports are going, not data ports in general!
>>>
>> Good. (At least, I think so.) ReadWrite dataports should not be an RTT
>> primitive, but should be an _architectural_ decision in your application,
>> in the sense that they represent the simplest(?) example of the the more
>> general concept of a "data component", that is, a component that is
>> responsible for all operations on a particular set of data, including
>> reading and writing from client components.
>
> Good point. What about the buffered ports? Wouldn't these too be
> better expressed as components with configurable types (lock-free,
> etc) and configurable capacities?
I think so...
> This quickly leads to the idea of composite components, which I think
> would be nice and important - but unfortunately not very easy.
Herman