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

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];
>> 

>> 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];
>> 

Herman

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];
> > 

> > 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];
> > 

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

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