Dear Sirs, I'm quite new to Orocos and I would like to create a wrapper component for Canfestival.
During the configuration, the component will execute the typical Canfestival initialization code ( which creates threads for receiving and dispatching canopen messages and for sending synch messages, pdos etc ).
The Canfestival object dictionary contains some Manufacturer Specific variables ( in index range 0x2000 - 0x5FFF ) which, in Canfestival, are protected against concurrent access by different threads with 'EnterMutex() - LeaveMutex()' Canfestival functions ( Canfestival makes these functions available ). My wrapper component will create some attributes / properties for making these Manufacturer Specific variables available in Orocos scripts.
I'd like to allow access to the Canfestival Manufacturer Specific variables in Orocos programs and state machines scripts, without the need to create 'EnterMutex() - LeaveMutex()' synchronization methods in the wrapper component and force the user of the component to use them whenever accessing this variables. For example this could be possible if a hook function exists, called before the execution of the script code, where I could call the 'EnterMutex()' Canfestival function, and a hook function, called after the execution of the script code, where I could call the 'LeaveMutex()' Canfestival function.
What is the best approach for doing this? Where I should put the 'EnterMutex() - LeaveMutex()' Canfestival functions in C++ code?
Thanks in advance and best regards Ettore
Synchronization issue in Orocos component Canfestival wrapper
On Fri, Jan 20, 2012 at 8:42 AM, <ediboscio [..] ...> wrote:
>
> Dear Sirs,
> I'm quite new to Orocos and I would like to create a wrapper component for
> Canfestival.
>
> During the configuration, the component will execute the typical Canfestival
> initialization code ( which creates threads for receiving and dispatching
> canopen messages and for sending synch messages, pdos etc ).
>
> The Canfestival object dictionary contains some Manufacturer Specific
> variables ( in index range 0x2000 - 0x5FFF ) which, in Canfestival, are
> protected against concurrent access by different threads with 'EnterMutex() -
> LeaveMutex()' Canfestival functions ( Canfestival makes these functions
> available ).
> My wrapper component will create some attributes / properties for making
> these Manufacturer Specific variables available in Orocos scripts.
>
> I'd like to allow access to the Canfestival Manufacturer Specific variables
> in Orocos programs and state machines scripts, without the need to create
> 'EnterMutex() - LeaveMutex()' synchronization methods in the wrapper
> component and force the user of the component to use them whenever accessing
> this variables.
> For example this could be possible if a hook function exists, called before
> the execution of the script code, where I could call the 'EnterMutex()'
> Canfestival function, and a hook function, called after the execution of the
> script code, where I could call the 'LeaveMutex()' Canfestival function.
>
> What is the best approach for doing this?
> Where I should put the 'EnterMutex() - LeaveMutex()' Canfestival functions in
> C++ code?
There are no hook functions available to execute before/after a
script. The quickest way is to make the Enter/LeaveMutex functions
component operations and let the scripts call them. The alternative is
to extend (derive from) the ScriptingService with a
CanFestivalScriptingService, which calls enter/leave before/after each
script executed. You'll then have to 'addService' this
CanFestivalScriptingService to your can festival wrapper component.
Peter
Synchronization issue in Orocos component Canfestival wrapper
I'm thinking to try the following:
1) The configureHook function of the wrapper component starts the Canfestival initialization procedure, which creates some threads. Than it waits for a flag, which is set from one of the callbacks called from Canfestival thread after its complete initialization:
bool configureHook() { init_done = false; ... int watchdog_counter = 0; while( watchdog_counter++ < 2000 && ! init_done ) usleep( 5000 ); if( ! init_done ) ... // error management ... }2) The initialization code in the Canfestival callback create a non periodic slave activity for the wrapper component: 3) after initialization, Canfestival starts firing synch events, calling a post_synch callback in a thread which has the higher priority in the whole system. Here I call wrapper->getActivity()->execute(); updateHook() is now being executed at each synch event in the same thread of the post_synch callback;Now, let's say that I create a completely different (without Canfestival) Orocos project where two periodic components exist, eventually with different priorities, one of them can get and set, in a script, the attributes/properties of the other thread-safely. A mechanism must have been developed in Orocos for allowing this. Is this mechanism working in my Canfestival wrapper scenario where the SlaveActivity is used to execute its ExecutionEngine, when an other component gets / sets the attributes / properties of the wrapper component?
In this case I could make the components communicate using these attributes / properties, and in the synchronized Canfestival post_synch callback ( already protected by the EnterMutex(), LeaveMutex() functions ), I could copy these attributes / properties to those Canfestival Manufacturer Specific variables.
Could this work?
Thanks in advance and Best Regards
Ettore
Synchronization issue in Orocos component Canfestival wrapper
2012/1/20 <ediboscio [..] ...>
> Dear Sirs,
> I'm quite new to Orocos and I would like to create a wrapper component for
> Canfestival.
>
> During the configuration, the component will execute the typical
> Canfestival
> initialization code ( which creates threads for receiving and dispatching
> canopen messages and for sending synch messages, pdos etc ).
>
> The Canfestival object dictionary contains some Manufacturer Specific
> variables ( in index range 0x2000 - 0x5FFF ) which, in Canfestival, are
> protected against concurrent access by different threads with
> 'EnterMutex() -
> LeaveMutex()' Canfestival functions ( Canfestival makes these functions
> available ).
> My wrapper component will create some attributes / properties for making
> these Manufacturer Specific variables available in Orocos scripts.
>
> I'd like to allow access to the Canfestival Manufacturer Specific variables
> in Orocos programs and state machines scripts, without the need to create
> 'EnterMutex() - LeaveMutex()' synchronization methods in the wrapper
> component and force the user of the component to use them whenever
> accessing
> this variables.
> For example this could be possible if a hook function exists, called before
> the execution of the script code, where I could call the 'EnterMutex()'
> Canfestival function, and a hook function, called after the execution of
> the
> script code, where I could call the 'LeaveMutex()' Canfestival function.
>
> What is the best approach for doing this?
> Where I should put the 'EnterMutex() - LeaveMutex()' Canfestival functions
> in
> C++ code?
>
> Thanks in advance and best regards
> Ettore
>
>
For your information, I know that they are several people trying to
interface CanFastival with Orocos (including me) in different manners.
Provinding a generic solution would be great, so don't hesitate to publish
;)
I am not a CanFestival expert, but be aware no to hold the mutex during the
underlying Can work (especially at sync time), this could introduce
latencies.
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
Synchronization issue in Orocos component Canfestival wrapper
Hi Ettore,
On Wed, Jan 25, 2012 at 11:29 AM, <ediboscio [..] ...> wrote:
> I'm thinking to try the following:
>
> 1) The configureHook function of the wrapper component starts the Canfestival
> initialization procedure, which creates some threads.
> Than it waits for a flag, which is set from one of the callbacks called from
> Canfestival thread after its complete initialization:
>
> bool configureHook()
> {
> init_done = false;
> ...
> int watchdog_counter = 0;
> while( watchdog_counter++ < 2000 && ! init_done ) usleep( 5000 );
> if( ! init_done ) ... // error management
> ...
> }
>
> 2) The initialization code in the Canfestival callback create a non periodic
> slave activity for the wrapper component:
>
> ...
> wrapper->setActivity( new RTT::extras::SlaveActivity() );
>
> 3) after initialization, Canfestival starts firing synch events, calling a
> post_synch callback in a thread which has the higher priority in the whole
> system.
> Here I call wrapper->getActivity()->execute();
> updateHook() is now being executed at each synch event in the same thread of
> the post_synch callback;
>
> Now, let's say that I create a completely different (without Canfestival)
> Orocos project where two periodic components exist, eventually with different
> priorities, one of them can get and set, in a script, the
> attributes/properties of the other thread-safely. A mechanism must have been
> developed in Orocos for allowing this. Is this mechanism working in my
> Canfestival wrapper scenario where the SlaveActivity is used to execute its
> ExecutionEngine, when an other component gets / sets the attributes /
> properties of the wrapper component?
Nope. This came up on the mailing list frequently, we don't support thread-safe
attribute-properties setting. Use ports to communicate between components.
The properties and attributes are for the component itself only and
modifying them
remotely is on your own risk.
Peter
Synchronization issue in Orocos component Canfestival wrapper
On Wed, 25 Jan 2012, Peter Soetens wrote:
> Hi Ettore,
On Wed, Jan 25, 2012 at 11:29 AM, <ediboscio [..] ...> wrote:
> I'm thinking to try the following:
>
> 1) The configureHook function of the wrapper component starts the Canfestival
> initialization procedure, which creates some threads.
> Than it waits for a flag, which is set from one of the callbacks called from
> Canfestival thread after its complete initialization:
>
> bool configureHook()
> {
> init_done = false;
> ...
> int watchdog_counter = 0;
> while( watchdog_counter++ < 2000 && ! init_done ) usleep( 5000 );
> if( ! init_done ) ... // error management
> ...
> }
>
> 2) The initialization code in the Canfestival callback create a non periodic
> slave activity for the wrapper component:
>
> ...
> wrapper->setActivity( new RTT::extras::SlaveActivity() );
>
> 3) after initialization, Canfestival starts firing synch events, calling a
> post_synch callback in a thread which has the higher priority in the whole
> system.
> Here I call wrapper->getActivity()->execute();
> updateHook() is now being executed at each synch event in the same thread of
> the post_synch callback;
>
> Now, let's say that I create a completely different (without Canfestival)
> Orocos project where two periodic components exist, eventually with different
> priorities, one of them can get and set, in a script, the
> attributes/properties of the other thread-safely. A mechanism must have been
> developed in Orocos for allowing this. Is this mechanism working in my
> Canfestival wrapper scenario where the SlaveActivity is used to execute its
> ExecutionEngine, when an other component gets / sets the attributes /
> properties of the wrapper component?
> Nope. This came up on the mailing list frequently, we don't support thread-safe
> attribute-properties setting. Use ports to communicate between components.
>
> The properties and attributes are for the component itself only and
> modifying them remotely is on your own risk.
I would go even further, and call this a "worst practice":
properties/attributes change the "behaviour" of a component towards its
peers, so a change in such behaviour should take place in an _atomic_ way
(that is, without the other components ever seeing inconsistent behaviour
of the component under reconfiguration). Practically speaking, and for all
except the most trivial behaviour changes, you should bring your component
in its configuration state (= consistent behviour towards its peers! maybe
not very useful, but that's another issue), do the reconfiguration via
synchronous (in-thread) calls, and then bring the component back in its
running state.
> Peter
Herman