Consolidation of Property and Attribute.

Hi Peter,

In Barcelona we decided to merge the two types, as it is often not
clear to new users when to use which one.

Is that still on the todo list or what is the status on this?

If Attribute is here to stays after all I will need to add Lua support
for it.

Thanks
Markus

Consolidation of Property and Attribute.

On Tue, 12 Oct 2010, Markus Klotzbuecher wrote:

> In Barcelona we decided to merge the two types, as it is often not
> clear to new users when to use which one.
Indeed. Semantically, a distinction _can_ be made, but it has no influence
on the software support:
- property: given to an object by nature
- attribute: given to an object by the human

Herman

> Is that still on the todo list or what is the status on this?
>
> If Attribute is here to stays after all I will need to add Lua support
> for it.
>
> Thanks
> Markus

Consolidation of Property and Attribute.

On Oct 12, 2010, at 05:22 , Herman Bruyninckx wrote:

> On Tue, 12 Oct 2010, Markus Klotzbuecher wrote:
>
>> In Barcelona we decided to merge the two types, as it is often not
>> clear to new users when to use which one.
> Indeed. Semantically, a distinction _can_ be made, but it has no influence
> on the software support:
> - property: given to an object by nature
> - attribute: given to an object by the human

What is the practical distinction between these two, Herman?

I would push for real-time property access also. Having to dump properties onto ports so that we can read them elsewhere in real-time is a pain.
S

Consolidation of Property and Attribute.

On Tue, 12 Oct 2010, S Roderick wrote:

> On Oct 12, 2010, at 05:22 , Herman Bruyninckx wrote:
>
>> On Tue, 12 Oct 2010, Markus Klotzbuecher wrote:
>>
>>> In Barcelona we decided to merge the two types, as it is often not
>>> clear to new users when to use which one.
>> Indeed. Semantically, a distinction _can_ be made, but it has no influence
>> on the software support:
>> - property: given to an object by nature
>> - attribute: given to an object by the human
>
> What is the practical distinction between these two, Herman?

None what so ever :-) As I mentioned: our software doesn't have to care
about this distinction.

> I would push for real-time property access also. Having to dump
> properties onto ports so that we can read them elsewhere in real-time is
> a pain.

What you describe is only _one_ of the use cases! The other one has existed
all the time already: during your Computations (_inside_ a component) you
have every access you like to whatever property value you like.

My first rule of realtime design is still: there is _only one_ realtime
process in a system, and you should put all _real_ realtime stuff there...

Herman

Consolidation of Property and Attribute.

On Tuesday 12 October 2010 13:21:43 Herman Bruyninckx wrote:
> On Tue, 12 Oct 2010, S Roderick wrote:
> > On Oct 12, 2010, at 05:22 , Herman Bruyninckx wrote:
> >> On Tue, 12 Oct 2010, Markus Klotzbuecher wrote:
> >>> In Barcelona we decided to merge the two types, as it is often not
> >>> clear to new users when to use which one.
> >>
> >> Indeed. Semantically, a distinction _can_ be made, but it has no
> >> influence on the software support:
> >> - property: given to an object by nature
> >> - attribute: given to an object by the human
> >
> > What is the practical distinction between these two, Herman?
>
> None what so ever :-) As I mentioned: our software doesn't have to care
> about this distinction.
>
> > I would push for real-time property access also. Having to dump
> > properties onto ports so that we can read them elsewhere in real-time is
> > a pain.
>
> What you describe is only _one_ of the use cases! The other one has existed
> all the time already: during your Computations (_inside_ a component) you
> have every access you like to whatever property value you like.
>
> My first rule of realtime design is still: there is _only one_ realtime
> process in a system, and you should put all _real_ realtime stuff there...

Time to wake up in a multi-core world. While one core's thread is doing IO,
the other core's thread is doing calculations. Both can be hard real-time (no
contention if cache permits it) I see no reason to put both in one process,
that's a principle of system architecture.

Peter

Consolidation of Property and Attribute.

On Tue, 12 Oct 2010, Peter Soetens wrote:

> On Tuesday 12 October 2010 13:21:43 Herman Bruyninckx wrote:
>> On Tue, 12 Oct 2010, S Roderick wrote:
>>> On Oct 12, 2010, at 05:22 , Herman Bruyninckx wrote:
>>>> On Tue, 12 Oct 2010, Markus Klotzbuecher wrote:
>>>>> In Barcelona we decided to merge the two types, as it is often not
>>>>> clear to new users when to use which one.
>>>>
>>>> Indeed. Semantically, a distinction _can_ be made, but it has no
>>>> influence on the software support:
>>>> - property: given to an object by nature
>>>> - attribute: given to an object by the human
>>>
>>> What is the practical distinction between these two, Herman?
>>
>> None what so ever :-) As I mentioned: our software doesn't have to care
>> about this distinction.
>>
>>> I would push for real-time property access also. Having to dump
>>> properties onto ports so that we can read them elsewhere in real-time is
>>> a pain.
>>
>> What you describe is only _one_ of the use cases! The other one has existed
>> all the time already: during your Computations (_inside_ a component) you
>> have every access you like to whatever property value you like.
>>
>> My first rule of realtime design is still: there is _only one_ realtime
>> process in a system, and you should put all _real_ realtime stuff there...
>
> Time to wake up in a multi-core world. While one core's thread is doing IO,
> the other core's thread is doing calculations. Both can be hard real-time (no
> contention if cache permits it) I see no reason to put both in one process,
> that's a principle of system architecture.

Time to wake up in real-time world. :-) The situation above is _not_ hard
realtime, although you seem to suggest that! It's the "roundtrip latency"
that really counts (that is, from core over busses over IO hardware to the
real world and back!) and not just the latencies of the _computations_ on
one single core...
In this context, multi-core is not a good thing for hard realtime
designers... It's making their job extremely hard, because of the many
undeterministic _interactions_ between cores and on-chip busses and caches.

Herman

Consolidation of Property and Attribute.

On Oct 12, 2010, at 07:21 , Herman Bruyninckx wrote:

> On Tue, 12 Oct 2010, S Roderick wrote:
>
>> On Oct 12, 2010, at 05:22 , Herman Bruyninckx wrote:
>>
>>> On Tue, 12 Oct 2010, Markus Klotzbuecher wrote:
>>>
>>>> In Barcelona we decided to merge the two types, as it is often not
>>>> clear to new users when to use which one.
>>> Indeed. Semantically, a distinction _can_ be made, but it has no influence
>>> on the software support:
>>> - property: given to an object by nature
>>> - attribute: given to an object by the human
>>
>> What is the practical distinction between these two, Herman?
>
> None what so ever :-) As I mentioned: our software doesn't have to care
> about this distinction.

Orthogonality. RTT has two almost identical things, where one might be more practical and less confusing.

>> I would push for real-time property access also. Having to dump
>> properties onto ports so that we can read them elsewhere in real-time is
>> a pain.
>
> What you describe is only _one_ of the use cases! The other one has existed
> all the time already: during your Computations (_inside_ a component) you
> have every access you like to whatever property value you like.

Are you sure about that? Real-time access to property values within a component? I don't believe that is what we discussed in Barcelona.

> My first rule of realtime design is still: there is _only one_ realtime
> process in a system, and you should put all _real_ realtime stuff there...

Process or component? We only ever have one real-time process per system. We do sometimes have multiple real-time systems communicating and cooperating together (the comm's is non-realtime).
S

Consolidation of Property and Attribute.

On Tue, 12 Oct 2010, Stephen Roderick wrote:

> On Oct 12, 2010, at 07:21 , Herman Bruyninckx wrote:
>
>> On Tue, 12 Oct 2010, S Roderick wrote:
>>
>>> On Oct 12, 2010, at 05:22 , Herman Bruyninckx wrote:
>>>
>>>> On Tue, 12 Oct 2010, Markus Klotzbuecher wrote:
>>>>
>>>>> In Barcelona we decided to merge the two types, as it is often not
>>>>> clear to new users when to use which one.
>>>> Indeed. Semantically, a distinction _can_ be made, but it has no influence
>>>> on the software support:
>>>> - property: given to an object by nature
>>>> - attribute: given to an object by the human
>>>
>>> What is the practical distinction between these two, Herman?
>>
>> None what so ever :-) As I mentioned: our software doesn't have to care
>> about this distinction.
>
> Orthogonality. RTT has two almost identical things, where one might be more practical and less confusing.
Exactly, that's why I suggest too to remove one of them :-) (I have the
impression I have not been able to get this message through :-)

>>> I would push for real-time property access also. Having to dump
>>> properties onto ports so that we can read them elsewhere in real-time is
>>> a pain.
>>
>> What you describe is only _one_ of the use cases! The other one has existed
>> all the time already: during your Computations (_inside_ a component) you
>> have every access you like to whatever property value you like.
>
> Are you sure about that? Real-time access to property values within a
> component? I don't believe that is what we discussed in Barcelona.

The property values are _loaded_ at initialisation time, and from then on
you have them at your disposal in realtime. It's up to you to write them
back, in non-realtime, when the component stops. (Or at any other moment in
its lifetime.)

Anyway, you can not define what 'realtime access' is, without knowing all
_runtime_ capabilities of all sofware and all hardware in the system.

>> My first rule of realtime design is still: there is _only one_ realtime
>> process in a system, and you should put all _real_ realtime stuff there...
>
> Process or component? We only ever have one real-time process per system.
> We do sometimes have multiple real-time systems communicating and
> cooperating together (the comm's is non-realtime).

That's the right architecture! :-)

Herman

Consolidation of Property and Attribute.

On Oct 12, 2010, at 09:55 , Herman Bruyninckx wrote:

> On Tue, 12 Oct 2010, Stephen Roderick wrote:
>
>> On Oct 12, 2010, at 07:21 , Herman Bruyninckx wrote:
>>
>>> On Tue, 12 Oct 2010, S Roderick wrote:
>>>
>>>> On Oct 12, 2010, at 05:22 , Herman Bruyninckx wrote:
>>>>
>>>>> On Tue, 12 Oct 2010, Markus Klotzbuecher wrote:
>>>>>
>>>>>> In Barcelona we decided to merge the two types, as it is often not
>>>>>> clear to new users when to use which one.
>>>>> Indeed. Semantically, a distinction _can_ be made, but it has no influence
>>>>> on the software support:
>>>>> - property: given to an object by nature
>>>>> - attribute: given to an object by the human
>>>>
>>>> What is the practical distinction between these two, Herman?
>>>
>>> None what so ever :-) As I mentioned: our software doesn't have to care
>>> about this distinction.
>>
>> Orthogonality. RTT has two almost identical things, where one might be more practical and less confusing.
> Exactly, that's why I suggest too to remove one of them :-) (I have the
> impression I have not been able to get this message through :-)

That didn't come across, sorry.

>>>> I would push for real-time property access also. Having to dump
>>>> properties onto ports so that we can read them elsewhere in real-time is
>>>> a pain.
>>>
>>> What you describe is only _one_ of the use cases! The other one has existed
>>> all the time already: during your Computations (_inside_ a component) you
>>> have every access you like to whatever property value you like.
>>
>> Are you sure about that? Real-time access to property values within a
>> component? I don't believe that is what we discussed in Barcelona.
>
> The property values are _loaded_ at initialisation time, and from then on
> you have them at your disposal in realtime. It's up to you to write them
> back, in non-realtime, when the component stops. (Or at any other moment in
> its lifetime.)

Sometimes we need to modify said properties from another component, or sometimes another process. Having to make the ports to support that in real-time is the additional headache we want to avoid.

> Anyway, you can not define what 'realtime access' is, without knowing all
> _runtime_ capabilities of all sofware and all hardware in the system.
>
>>> My first rule of realtime design is still: there is _only one_ realtime
>>> process in a system, and you should put all _real_ realtime stuff there...
>>
>> Process or component? We only ever have one real-time process per system.
>> We do sometimes have multiple real-time systems communicating and
>> cooperating together (the comm's is non-realtime).
>
> That's the right architecture! :-)
>
> Herman

Consolidation of Property and Attribute.

On Tue, 12 Oct 2010, Stephen Roderick wrote:

> On Oct 12, 2010, at 09:55 , Herman Bruyninckx wrote:
>
>> On Tue, 12 Oct 2010, Stephen Roderick wrote:
>>
>>> On Oct 12, 2010, at 07:21 , Herman Bruyninckx wrote:
>>>
>>>> On Tue, 12 Oct 2010, S Roderick wrote:
>>>>
>>>>> On Oct 12, 2010, at 05:22 , Herman Bruyninckx wrote:
>>>>>
>>>>>> On Tue, 12 Oct 2010, Markus Klotzbuecher wrote:
>>>>>>
>>>>>>> In Barcelona we decided to merge the two types, as it is often not
>>>>>>> clear to new users when to use which one.
>>>>>> Indeed. Semantically, a distinction _can_ be made, but it has no influence
>>>>>> on the software support:
>>>>>> - property: given to an object by nature
>>>>>> - attribute: given to an object by the human
>>>>>
>>>>> What is the practical distinction between these two, Herman?
>>>>
>>>> None what so ever :-) As I mentioned: our software doesn't have to care
>>>> about this distinction.
>>>
>>> Orthogonality. RTT has two almost identical things, where one might be more practical and less confusing.
>> Exactly, that's why I suggest too to remove one of them :-) (I have the
>> impression I have not been able to get this message through :-)
>
> That didn't come across, sorry.

Then that's _my_ fault, and not the readers' :-(

>>>>> I would push for real-time property access also. Having to dump
>>>>> properties onto ports so that we can read them elsewhere in real-time is
>>>>> a pain.
>>>>
>>>> What you describe is only _one_ of the use cases! The other one has existed
>>>> all the time already: during your Computations (_inside_ a component) you
>>>> have every access you like to whatever property value you like.
>>>
>>> Are you sure about that? Real-time access to property values within a
>>> component? I don't believe that is what we discussed in Barcelona.
>>
>> The property values are _loaded_ at initialisation time, and from then on
>> you have them at your disposal in realtime. It's up to you to write them
>> back, in non-realtime, when the component stops. (Or at any other moment in
>> its lifetime.)
>
> Sometimes we need to modify said properties from another component, or
> sometimes another process. Having to make the ports to support that in
> real-time is the additional headache we want to avoid.

Why? The _runtime efficiency_ of the "port" concept depends on (i) the
implementation, (ii) the platform, and (iii) the deployment.
In this context: Orocos needs to evolve towards a better deployment tool
support that allows the designer to "think" in the component-level concept
of a Port, while the implementation and deployment reduce this (in the
automatically generated code) to access to a shared data value.

>> Anyway, you can not define what 'realtime access' is, without knowing all
>> _runtime_ capabilities of all sofware and all hardware in the system.
>>
>>>> My first rule of realtime design is still: there is _only one_ realtime
>>>> process in a system, and you should put all _real_ realtime stuff there...
>>>
>>> Process or component? We only ever have one real-time process per system.
>>> We do sometimes have multiple real-time systems communicating and
>>> cooperating together (the comm's is non-realtime).
>>
>> That's the right architecture! :-)

Herman

Consolidation of Property and Attribute.

> I would push for real-time property access also. Having to dump properties
> onto ports so that we can read them elsewhere in real-time is a pain.
>
>
+1

Davide

Consolidation of Property and Attribute.

On Tuesday 12 October 2010 13:15:06 Davide Faconti wrote:
> > I would push for real-time property access also. Having to dump
> > properties onto ports so that we can read them elsewhere in real-time is
> > a pain.
>
> +1

This is our situation:

The only thread-safe primitives are ports and operations executed in the
component's thread (1.x Command or 2.x OwnThread flag).

Attributes are meant for 'intra-component', lightweight communication between
functions running in the same thread (just like a class attribute). There's no
reason to burden these with a thread-safe feature.

Properties *are* used to configure a component from the outside, and the
outside is *always* another thread. Unfortunately, since Properties were
initially thought of as a configuration-time primitive, it was reasoned that
they were only modified if the component's thread was not running or doing any
calculation. It was proposed that any run-time change had to be done with
commands OR methods which used mutexes to protect the data. The 2.x release
did not change this reasoning.

Users perceive it easier to create properties than to create an
operation/command for each parameter they want to change at run-time. I can't
deny the fact that 'run-time' properties are an often requested feature.
Unfortunately, the way in which we use properties exclude by all means thread
safety. For example, in 2.x, we add properties as such:


vector<double> parameters(10, 0.0); // 10 parameters all zero
this->addProperty("parameters", parameters); // takes a *reference* !

// write a property: can never be made thread-safe ! :
parameters[3] = 5.0;

// read is not thread safe either:
double k = parameters[5];


The only way to make 'paramters' thread-safe is by guarding all access by
method calls. For example:


vector<double> parameters(10, 0.0); // 10 parameters all zero
Property<vector<double> > threadsafe_param = this->addProperty("parameters", 
parameters); // takes a *copy* !

// write a property: takes a *copy* first
parameters = threadsafe_param.read();
// ok
parameters[3] = 5.0
threadsafe_param.write( parameters ); // race here

// read a property
parameters = threadsafe_param.read();
double k = parameters[5];


These will prevent you from accessing a single element in the struct (you need
to read or write *all*) and each write will need a read first, possible
overwriting an interim read-write cycle of another thread. A classical race
condition.

I wonder if we will be better off. In this scenario, ports or operations offer
much more determinism, but they 'feel' less natural.

Anyone that dares to propose a thread-safe, natural Property API is mostly
welcome.

Peter

Consolidation of Property and Attribute.

On Oct 12, 2010, at 10:25 , Peter Soetens wrote:

> On Tuesday 12 October 2010 13:15:06 Davide Faconti wrote:
>>> I would push for real-time property access also. Having to dump
>>> properties onto ports so that we can read them elsewhere in real-time is
>>> a pain.
>>
>> +1
>
> This is our situation:
>
> The only thread-safe primitives are ports and operations executed in the
> component's thread (1.x Command or 2.x OwnThread flag).
>
> Attributes are meant for 'intra-component', lightweight communication between
> functions running in the same thread (just like a class attribute). There's no
> reason to burden these with a thread-safe feature.
>
> Properties *are* used to configure a component from the outside, and the
> outside is *always* another thread. Unfortunately, since Properties were
> initially thought of as a configuration-time primitive, it was reasoned that
> they were only modified if the component's thread was not running or doing any
> calculation. It was proposed that any run-time change had to be done with
> commands OR methods which used mutexes to protect the data. The 2.x release
> did not change this reasoning.

We avoided the commands/methods mess by using ports (as Herman is suggesting) to represent properties that need runtime configuration. The overhead is that we have to manually create a port for each property, and sync the ports and properties on component startup and shutdown. A working solution, just more overhead each time than we'd like.

> Users perceive it easier to create properties than to create an
> operation/command for each parameter they want to change at run-time. I can't
> deny the fact that 'run-time' properties are an often requested feature.

"Perceive" - it is definitely easier to create a property than mess with commands (in v1)!

> Unfortunately, the way in which we use properties exclude by all means thread
> safety. For example, in 2.x, we add properties as such:
>
> 
> vector<double> parameters(10, 0.0); // 10 parameters all zero
> this->addProperty("parameters", parameters); // takes a *reference* !
> 
> // write a property: can never be made thread-safe ! :
> parameters[3] = 5.0;
> 
> // read is not thread safe either:
> double k = parameters[5];
>
>
> The only way to make 'paramters' thread-safe is by guarding all access by
> method calls. For example:
>
> 
> vector<double> parameters(10, 0.0); // 10 parameters all zero
> Property<vector<double> > threadsafe_param = this->addProperty("parameters", 
> parameters); // takes a *copy* !
> 
> // write a property: takes a *copy* first
> parameters = threadsafe_param.read();
> // ok
> parameters[3] = 5.0
> threadsafe_param.write( parameters ); // race here
> 
> // read a property
> parameters = threadsafe_param.read();
> double k = parameters[5];
>
>
> These will prevent you from accessing a single element in the struct (you need
> to read or write *all*) and each write will need a read first, possible
> overwriting an interim read-write cycle of another thread. A classical race
> condition.
>
> I wonder if we will be better off. In this scenario, ports or operations offer
> much more determinism, but they 'feel' less natural.
>
> Anyone that dares to propose a thread-safe, natural Property API is mostly
> welcome.

I definitely prefer your proposed serialization approach to the above nightmare.
S

Consolidation of Property and Attribute.

On Thu, 14 Oct 2010, Stephen Roderick wrote:

> On Oct 12, 2010, at 10:25 , Peter Soetens wrote:
>
>> On Tuesday 12 October 2010 13:15:06 Davide Faconti wrote:
>>>> I would push for real-time property access also. Having to dump
>>>> properties onto ports so that we can read them elsewhere in real-time is
>>>> a pain.
>>>
>>> +1
>>
>> This is our situation:
>>
>> The only thread-safe primitives are ports and operations executed in the
>> component's thread (1.x Command or 2.x OwnThread flag).
>>
>> Attributes are meant for 'intra-component', lightweight communication between
>> functions running in the same thread (just like a class attribute). There's no
>> reason to burden these with a thread-safe feature.
>>
>> Properties *are* used to configure a component from the outside, and the
>> outside is *always* another thread. Unfortunately, since Properties were
>> initially thought of as a configuration-time primitive, it was reasoned that
>> they were only modified if the component's thread was not running or doing any
>> calculation. It was proposed that any run-time change had to be done with
>> commands OR methods which used mutexes to protect the data. The 2.x release
>> did not change this reasoning.
>
> We avoided the commands/methods mess by using ports (as Herman is suggesting) to represent properties that need runtime configuration. The overhead is that we have to manually create a port for each property, and sync the ports and properties on component startup and shutdown. A working solution, just more overhead each time than we'd like.

Yes, it makes senses to have a "property service", i.e., one "wire" that is
ready to service all property sets and gets.

>> Users perceive it easier to create properties than to create an
>> operation/command for each parameter they want to change at run-time. I can't
>> deny the fact that 'run-time' properties are an often requested feature.
>
> "Perceive" - it is definitely easier to create a property than mess with
> commands (in v1)!

A property service would have trivial "built-in" commands: set, get.

>> Unfortunately, the way in which we use properties exclude by all means thread
>> safety. For example, in 2.x, we add properties as such:
>>
>> 
>> vector<double> parameters(10, 0.0); // 10 parameters all zero
>> this->addProperty("parameters", parameters); // takes a *reference* !
>>
>> // write a property: can never be made thread-safe ! :
>> parameters[3] = 5.0;
>>
>> // read is not thread safe either:
>> double k = parameters[5];
>>
>>
>> The only way to make 'paramters' thread-safe is by guarding all access by
>> method calls. For example:
>>
>> 
>> vector<double> parameters(10, 0.0); // 10 parameters all zero
>> Property<vector<double> > threadsafe_param = this->addProperty("parameters",
>> parameters); // takes a *copy* !
>>
>> // write a property: takes a *copy* first
>> parameters = threadsafe_param.read();
>> // ok
>> parameters[3] = 5.0
>> threadsafe_param.write( parameters ); // race here
>>
>> // read a property
>> parameters = threadsafe_param.read();
>> double k = parameters[5];
>>
>>
>> These will prevent you from accessing a single element in the struct (you need
>> to read or write *all*) and each write will need a read first, possible
>> overwriting an interim read-write cycle of another thread. A classical race
>> condition.
>>
>> I wonder if we will be better off. In this scenario, ports or operations offer
>> much more determinism, but they 'feel' less natural.
>>
>> Anyone that dares to propose a thread-safe, natural Property API is mostly
>> welcome.
>
>
> I definitely prefer your proposed serialization approach to the above nightmare.

Herman

Consolidation of Property and Attribute.

On Tue, 12 Oct 2010, Peter Soetens wrote:

> On Tuesday 12 October 2010 13:15:06 Davide Faconti wrote:
>>> I would push for real-time property access also. Having to dump
>>> properties onto ports so that we can read them elsewhere in real-time is
>>> a pain.
>>
>> +1
>
> This is our situation:
>
> The only thread-safe primitives are ports and operations executed in the
> component's thread (1.x Command or 2.x OwnThread flag).
>
> Attributes are meant for 'intra-component', lightweight communication between
> functions running in the same thread (just like a class attribute). There's no
> reason to burden these with a thread-safe feature.
>
> Properties *are* used to configure a component from the outside, and the
> outside is *always* another thread.

Good explanation! Why? Because it makes the real cause of the problem
surface: different _deployment_ use cases of the same thing.

The real solution, in my opinion, is to provide one single programming
primitive (at least at the component level), namely the "port", and make
sure both use cases are seamlessly supported by the deployment toolchain.

> Unfortunately, since Properties were
> initially thought of as a configuration-time primitive, it was reasoned that
> they were only modified if the component's thread was not running or doing any
> calculation.

This should again not make any difference at _design_ time, but at
deployment time.

> It was proposed that any run-time change had to be done with
> commands OR methods which used mutexes to protect the data. The 2.x release
> did not change this reasoning.
>
> Users perceive it easier to create properties than to create an
> operation/command for each parameter they want to change at run-time. I can't
> deny the fact that 'run-time' properties are an often requested feature.
> Unfortunately, the way in which we use properties exclude by all means thread
> safety. For example, in 2.x, we add properties as such:
>
> 
> vector<double> parameters(10, 0.0); // 10 parameters all zero
> this->addProperty("parameters", parameters); // takes a *reference* !
>
> // write a property: can never be made thread-safe ! :
> parameters[3] = 5.0;
>
> // read is not thread safe either:
> double k = parameters[5];
>
>
> The only way to make 'paramters' thread-safe is by guarding all access by
> method calls. For example:
>
> 
> vector<double> parameters(10, 0.0); // 10 parameters all zero
> Property<vector<double> > threadsafe_param = this->addProperty("parameters",
> parameters); // takes a *copy* !
>
> // write a property: takes a *copy* first
> parameters = threadsafe_param.read();
> // ok
> parameters[3] = 5.0
> threadsafe_param.write( parameters ); // race here
>
> // read a property
> parameters = threadsafe_param.read();
> double k = parameters[5];
>
>
> These will prevent you from accessing a single element in the struct (you need
> to read or write *all*) and each write will need a read first, possible
> overwriting an interim read-write cycle of another thread. A classical race
> condition.
>
> I wonder if we will be better off. In this scenario, ports or operations offer
> much more determinism, but they 'feel' less natural.
>
> Anyone that dares to propose a thread-safe, natural Property API is mostly
> welcome.

Thread-safety is the nicest property of the Ports, and please, let's keep
it this way! Only the _toolchain support_ should become more flexible. It
would be stupid to give up on the _semantics_ just for some people's
efficiency "problems". Both can and should be solved at the right level,
and that level is _definitely_ not the "component API" specification.

Herman

Consolidation of Property and Attribute.

On Tuesday 12 October 2010 16:33:05 Herman Bruyninckx wrote:
> On Tue, 12 Oct 2010, Peter Soetens wrote:
> > On Tuesday 12 October 2010 13:15:06 Davide Faconti wrote:
> >>> I would push for real-time property access also. Having to dump
> >>> properties onto ports so that we can read them elsewhere in real-time
> >>> is a pain.
> >>
> >> +1
> >
> > This is our situation:
> >
> > The only thread-safe primitives are ports and operations executed in the
> > component's thread (1.x Command or 2.x OwnThread flag).
> >
> > Attributes are meant for 'intra-component', lightweight communication
> > between functions running in the same thread (just like a class
> > attribute). There's no reason to burden these with a thread-safe
> > feature.
> >
> > Properties *are* used to configure a component from the outside, and the
> > outside is *always* another thread.
>
> Good explanation! Why? Because it makes the real cause of the problem
> surface: different _deployment_ use cases of the same thing.
>
> The real solution, in my opinion, is to provide one single programming
> primitive (at least at the component level), namely the "port", and make
> sure both use cases are seamlessly supported by the deployment toolchain.
>
> > Unfortunately, since Properties were
> > initially thought of as a configuration-time primitive, it was reasoned
> > that they were only modified if the component's thread was not running
> > or doing any calculation.
>
> This should again not make any difference at _design_ time, but at
> deployment time.
>
> > It was proposed that any run-time change had to be done with
> > commands OR methods which used mutexes to protect the data. The 2.x
> > release did not change this reasoning.
> >
> > Users perceive it easier to create properties than to create an
> > operation/command for each parameter they want to change at run-time. I
> > can't deny the fact that 'run-time' properties are an often requested
> > feature. Unfortunately, the way in which we use properties exclude by
> > all means thread safety. For example, in 2.x, we add properties as such:
> >
> > 
> > vector<double> parameters(10, 0.0); // 10 parameters all zero
> > this->addProperty("parameters", parameters); // takes a *reference* !
> > 
> > // write a property: can never be made thread-safe ! :
> > parameters[3] = 5.0;
> > 
> > // read is not thread safe either:
> > double k = parameters[5];
> >
> >
> > The only way to make 'paramters' thread-safe is by guarding all access by
> > method calls. For example:
> >
> > 
> > vector<double> parameters(10, 0.0); // 10 parameters all zero
> > Property<vector<double> > threadsafe_param =
> > this->addProperty("parameters", parameters); // takes a *copy* !
> > 
> > // write a property: takes a *copy* first
> > parameters = threadsafe_param.read();
> > // ok
> > parameters[3] = 5.0
> > threadsafe_param.write( parameters ); // race here
> > 
> > // read a property
> > parameters = threadsafe_param.read();
> > double k = parameters[5];
> >
> >
> > These will prevent you from accessing a single element in the struct (you
> > need to read or write *all*) and each write will need a read first,
> > possible overwriting an interim read-write cycle of another thread. A
> > classical race condition.
> >
> > I wonder if we will be better off. In this scenario, ports or operations
> > offer much more determinism, but they 'feel' less natural.
> >
> > Anyone that dares to propose a thread-safe, natural Property API is
> > mostly welcome.
>
> Thread-safety is the nicest property of the Ports, and please, let's keep
> it this way! Only the _toolchain support_ should become more flexible. It
> would be stupid to give up on the _semantics_ just for some people's
> efficiency "problems". Both can and should be solved at the right level,
> and that level is _definitely_ not the "component API" specification.

I understand your arguments, and we see them reflected in reality. For example,
in ROS, lots of topics (= artifacts of data flow ports ) are used for
configuration of run-time variables. The yaml configuration format they have is
only for more static configuration, ie, persistent characteristics that are
loaded by a component during startup.

So I record your vote as a vote for the 'properties are accessed using ports
(in a service)'. This would also improve our ROS compatibility by the way...

Peter

Consolidation of Property and Attribute.

On Oct 12, 2010, at 10:33 , Herman Bruyninckx wrote:

> On Tue, 12 Oct 2010, Peter Soetens wrote:
>
>> On Tuesday 12 October 2010 13:15:06 Davide Faconti wrote:
>>>> I would push for real-time property access also. Having to dump
>>>> properties onto ports so that we can read them elsewhere in real-time is
>>>> a pain.
>>>
>>> +1
>>
>> This is our situation:
>>
>> The only thread-safe primitives are ports and operations executed in the
>> component's thread (1.x Command or 2.x OwnThread flag).
>>
>> Attributes are meant for 'intra-component', lightweight communication between
>> functions running in the same thread (just like a class attribute). There's no
>> reason to burden these with a thread-safe feature.
>>
>> Properties *are* used to configure a component from the outside, and the
>> outside is *always* another thread.
>
> Good explanation! Why? Because it makes the real cause of the problem
> surface: different _deployment_ use cases of the same thing.
>
> The real solution, in my opinion, is to provide one single programming
> primitive (at least at the component level), namely the "port", and make
> sure both use cases are seamlessly supported by the deployment toolchain.

Just looking at some of our code and I realised that there is a use case difference between properties and attributes. Namely, providing constant values from C++ code up into scripting (eg constants). A property is really heavy weight for that ... Davide has it above; attributes are script/state-machine level class values. We don't use them often, but we do use them.
S

Consolidation of Property and Attribute.

On Wed, 27 Oct 2010, S Roderick wrote:

> On Oct 12, 2010, at 10:33 , Herman Bruyninckx wrote:
>
>> On Tue, 12 Oct 2010, Peter Soetens wrote:
>>
>>> On Tuesday 12 October 2010 13:15:06 Davide Faconti wrote:
>>>>> I would push for real-time property access also. Having to dump
>>>>> properties onto ports so that we can read them elsewhere in real-time is
>>>>> a pain.
>>>>
>>>> +1
>>>
>>> This is our situation:
>>>
>>> The only thread-safe primitives are ports and operations executed in the
>>> component's thread (1.x Command or 2.x OwnThread flag).
>>>
>>> Attributes are meant for 'intra-component', lightweight communication between
>>> functions running in the same thread (just like a class attribute). There's no
>>> reason to burden these with a thread-safe feature.
>>>
>>> Properties *are* used to configure a component from the outside, and the
>>> outside is *always* another thread.
>>
>> Good explanation! Why? Because it makes the real cause of the problem
>> surface: different _deployment_ use cases of the same thing.
>>
>> The real solution, in my opinion, is to provide one single programming
>> primitive (at least at the component level), namely the "port", and make
>> sure both use cases are seamlessly supported by the deployment toolchain.
>
> Just looking at some of our code and I realised that there is a use case difference between properties and attributes. Namely, providing constant values from C++ code up into scripting (eg constants). A property is really heavy weight for that ... Davide has it above; attributes are script/state-machine level class values. We don't use them often, but we do use them.
> S

I will throw in, once again, my mantra: all the points raised in this
thread about "heavy weight" etc are true but they are _always_ a reflection
of the _policies_ used to change properties/attributes, not about the
essential aspect of properties/attributes (= changeable values that
influence the behaviour of a component), so we should discuss how to best
support the different _policies_ and not trying to give a different meaning
to the fundamental aspect of a property/attribute. The "heavyness" comes
from a lack of approprite _tooling_, not from a design error or
inappropriateness.

More concretely:
- the "port" is the right _conceptual_ way to go, _because_ it's the only
one that is portable from single-threaded to multi-threaded to
multi-process to multi-platform deployments;
- the _use_ of ports must be made simpler, for the human developer
- the _implementation_ of ports must be made efficient, by appropriate
deployment tooling (such as, the toolchain support to make a port into
shared memory in the deployment case of single threading).

Herman

Herman