On Oct 16, 2010, at 09:18 , Peter Soetens wrote:

> On Fri, Oct 15, 2010 at 4:39 PM, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
>> On Oct 14, 2010, at 10:58 , Peter Soetens wrote:
>>
>>> On Thu, Oct 14, 2010 at 2:29 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
>>>> On Oct 13, 2010, at 04:30 , Ruben Smits wrote:
>>>>
>>>>> On Wednesday 13 October 2010 10:16:39 Peter Soetens wrote:
>>>>>> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=788
>>>>>>
>>>>>> Summary: Thread-safe property service
>>>>>> Product: Toolchain
>>>>>> Version: unspecified
>>>>>> Platform: All
>>>>>> OS/Version: All
>>>>>> Status: NEW
>>>>>> Severity: enhancement
>>>>>> Priority: P3
>>>>>> Component: RTT
>>>>>> AssignedTo: orocos-dev [..] ...
>>>>>> ReportedBy: peter [..] ...
>>>>>> CC: orocos-dev [..] ...
>>>>>> Estimated Hours: 0.0
>>>>>>
>>>>>>
>>>>>> Idea: To add a service plugin, similar to "marshalling", which provides
>>>>>> thread-safe read/write access to all properties of a component.
>>>>>>
>>>>>> Technical realisation:
>>>>>> Serialize reading and writing component properties with updateHook(). As
>>>>>> such, the same level of thread-safeness as operations' is provided.
>>>>>>
>>>>>> Possible Features (pick one/some):
>>>>>> - The service mirrors the property tree of the component, but each
>>>>>> read/write will be thread-safe. The component's original properties get
>>>>>> updated before updateHook().
>>>>>> - The service can create in or out ports for each property and
>>>>>> reading/writing these ports modifies the properties (in the next
>>>>>> updateHook cycle). - The service provides a
>>>>>> readProperty("name")/writeProperty("name",value) operation pair(s). It's
>>>>>> unclear how different types of 'value' can be handled or how 'value' can
>>>>>> be a generic container for any data. These operations could be 'OwnThread'
>>>>>> type, using this feature to provide the thread-safety.
>>>>>>
>>>>>> Implementation details:
>>>>>> The service may install itself as a base::ExecutableInterface in the
>>>>>> ExecutionEngine. In its execute() method, it will implement the read/write
>>>>>> of the properties and it will need to track which ones changed and in
>>>>>> which direction. Or the service registers 'OwnThread' read/write
>>>>>> operations, which will be serialized with updateHook by design.
>>>>>
>>>>> +1
>>>>
>>>> +1
>>>>
>>>> To paraphrase, another component, or process via CORBA, could read/write properties multi-thread and real-time safe. This can either be done by direct access to the service's operations, or via ports if we chose to get the service to create those.
>>>>
>>>> Are the two options listed an either/or, or are you thinking of doing both?
>>>
>>> I'd like to stick to one system for the first implementation. Other
>>> services aiming to solve the same problem may choose other policies of
>>> course.
>>
>> I am unsure which to choose. Automatically creating lots of extra ports will make it confusing to wade through some components interfaces, though ports are nice an easy to connect to, etc. But how hard would it be to connect to the property service from an external process like a GUI?
>
> It will be the same like using any service: using the RTT's API or
> using the IDL directly. This is a bit more complex than using the
> ConfigurationInterface (v2.x), which allows to read/write properties
> directly, but not thread-safe. We could have an option that using that
> interface, while the component is Running, is forbidden.
>
>>
>>>> Will the serialized updates occur before state machines are run this cycle (as with update hook)?
>>>
>>> Yes, before updateHook(). Both scripting and the thread-safe prop
>>> service would run in the EE's function queue, so the order of
>>> execution would depend on the order of loading the services.
>>>
>>>>
>>>> Will the updateHook() of a component be able to access it's own properties in real-time?
>>>
>>> That's the whole idea. updateHook() + each OwnThread operation will be
>>> able to use the normal properties, as before. So the component
>>> implementation doesn't change a single line. It's the accessing from
>>> outside that must take another path.
>>
>> What is the case with RTT v1 now? Can a component access it's own properties in real-time from within an updateHook()?
>
> Of course. You can use the value() or rvalue() methods to get a
> (const) reference to the internals of the property, so avoiding any
> copies.
>
>>
>>>> What is the value type problem?
>>>
>>> It's technical, but an off-list chat with type-system expert Markus
>>> offered some possibilities I didn't think about before. The problem is
>>> that we don't want to generate a 'writeProperty("name", value)' for
>>> each type T of value. But it's possible to write a generic version
>>> that internally uses only datasources. The calling of
>>> read/writeProperty would not be real-time for the caller in that case
>>> (needs to create data sources on the heap). But that might be
>>> acceptible.
>>
>> Does this lean more towards the port approach then? If real-time access versus just multi-component/thread access is favored?
>
> If you want to modify parameters of components in real-time, they
> should have been ports in the first place. I don't consider changing
> properties of another component in real-time a planned feature.

Agreed, but if you are initializing said ports from properties at startup, and want to write the final values back at shutdown, then this leans towards using the modify-properties-over-ports approach. Right? While this isn't a common use case for us, it does occur.
S