Hi,
I would like to do something like a parallel deployment for a bunch of
component. That means that I would like to call all "configure" function in
parallel without blocking because they are a bit long, and call for all of
them component.isConfigured() to check the end of this. This is done in the
configureHook of a monitoring component that is responsible to manage all
this.
Is there anything existing to do this ?
Should I use a particular "configure" function or should I spawn one thread
by conpoment to configure ?
Is there any problem if several threads calls configureHook on the same
component ?
What's behind this, is that I wait for some hardware synchronisation in
configureHook of low level components. I think the real problem is that I
use the configureHook that is at framework level instead of a particular
running state that would be more a functionnal level. I know this will hurt
Hermann (^^) but I'm stucked with this now, and I have no time to change
that.
Non blocking configure/start/stop/cleanup function for parallel
On Fri, 21 Sep 2012, Willy Lambert wrote:
> Hi,
>
> I would like to do something like a parallel deployment for a bunch of component. That means
> that I would like to call all "configure" function in parallel without blocking because they are
> a bit long, and call for all of them component.isConfigured() to check the end of this. This is
> done in the configureHook of a monitoring component that is responsible to manage all this.
>
> Is there anything existing to do this ?
> Should I use a particular "configure" function or should I spawn one thread by conpoment to
> configure ?
The _logic_ of your deployment should be robust against both modes of
deployment.
> Is there any problem if several threads calls configureHook on the same component ?
Oops, that sounds like a design error to me (violating "ownership" of
components). But on the other hand, the component implementations should be
robust against this. In the context of configuration, this means that each
component should keep track of what it has already done wrt configuration.
This is also "state", but it makes more sense to keep that state in a data
structure instead of putting it into a state machine.
>
> What's behind this, is that I wait for some hardware synchronisation in configureHook of low
> level components. I think the real problem is that I use the configureHook that is at framework
> level instead of a particular running state that would be more a functionnal level. I know this
> will hurt Hermann (^^)
It will not :-) The concept of synchronisation by letting different state
machines wait for a set of events is a fine pattern, at any level of
"component abstraction".
> but I'm stucked with this now, and I have no time to change that.
Herman
Non blocking configure/start/stop/cleanup function for parallel
2012/9/21 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Fri, 21 Sep 2012, Willy Lambert wrote:
>
> Hi,
>>
>> I would like to do something like a parallel deployment for a bunch of
>> component. That means
>> that I would like to call all "configure" function in parallel without
>> blocking because they are
>> a bit long, and call for all of them component.isConfigured() to check
>> the end of this. This is
>> done in the configureHook of a monitoring component that is responsible
>> to manage all this.
>>
>> Is there anything existing to do this ?
>> Should I use a particular "configure" function or should I spawn one
>> thread by conpoment to
>> configure ?
>>
>
> The _logic_ of your deployment should be robust against both modes of
> deployment.
It is, it's a matter of reducing deployment delays
>
>
> Is there any problem if several threads calls configureHook on the same
>> component ?
>>
>
> Oops, that sounds like a design error to me (violating "ownership" of
> components). But on the other hand, the component implementations should be
> robust against this. In the context of configuration, this means that each
> component should keep track of what it has already done wrt configuration.
> This is also "state", but it makes more sense to keep that state in a data
> structure instead of putting it into a state machine.
Yes, of course, my question is more about Orocos behavior in such
situation. if I were using operation as Sylvain suggested I wouldn't have
any problem (because I think it is handled), but I don't know what's
happening when I'm just using TaskContext.configure() directly in C++. I'm
afraid that the Operation call interface is bypassed.
>
>
>> What's behind this, is that I wait for some hardware synchronisation in
>> configureHook of low
>> level components. I think the real problem is that I use the
>> configureHook that is at framework
>> level instead of a particular running state that would be more a
>> functionnal level. I know this
>> will hurt Hermann (^^)
>>
>
> It will not :-) The concept of synchronisation by letting different state
> machines wait for a set of events is a fine pattern, at any level of
> "component abstraction".
>
>
> but I'm stucked with this now, and I have no time to change that.
>>
>
> Herman
>
Non blocking configure/start/stop/cleanup function for parallel
On Fri, 21 Sep 2012, Willy Lambert wrote:
>
>
> 2012/9/21 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Fri, 21 Sep 2012, Willy Lambert wrote:
>
> Hi,
>
> I would like to do something like a parallel deployment for a bunch of
> component. That means
> that I would like to call all "configure" function in parallel without
> blocking because they are
> a bit long, and call for all of them component.isConfigured() to check
> the end of this. This is
> done in the configureHook of a monitoring component that is responsible
> to manage all this.
>
> Is there anything existing to do this ?
> Should I use a particular "configure" function or should I spawn one
> thread by conpoment to
> configure ?
>
>
> The _logic_ of your deployment should be robust against both modes of
> deployment.
>
> It is, it's a matter of reducing deployment delays
Do you mean that you still have problems in your deployment because of
delays? In that case, your deployment logic is _not_ robust...
> Is there any problem if several threads calls configureHook on the same
> component ?
>
> Oops, that sounds like a design error to me (violating "ownership" of
> components). But on the other hand, the component implementations should be
> robust against this. In the context of configuration, this means that each
> component should keep track of what it has already done wrt configuration.
> This is also "state", but it makes more sense to keep that state in a data
> structure instead of putting it into a state machine.
>
> Yes, of course, my question is more about Orocos behavior in such situation. if I were using
> operation as Sylvain suggested I wouldn't have any problem (because I think it is handled), but
> I don't know what's happening when I'm just using TaskContext.configure() directly in C++. I'm
> afraid that the Operation call interface is bypassed.
This sounds like a (one of the many...) "semantic variation points" that we
still have in RTT. I would welcome an overview of all of these, so that we
can think together about "the" solution to solve them. Because one of the
worst thing a software framework can have is uncertainty about its
behavioural model.
> What's behind this, is that I wait for some hardware synchronisation in
> configureHook of low
> level components. I think the real problem is that I use the
> configureHook that is at framework
> level instead of a particular running state that would be more a
> functionnal level. I know this
> will hurt Hermann (^^)
>
> It will not :-) The concept of synchronisation by letting different state
> machines wait for a set of events is a fine pattern, at any level of
> "component abstraction".
>
> but I'm stucked with this now, and I have no time to change that.
Herman
Non blocking configure/start/stop/cleanup function for parallel
2012/9/21 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Fri, 21 Sep 2012, Willy Lambert wrote:
>
>
>>
>> 2012/9/21 Herman Bruyninckx <Herman.Bruyninckx@mech.**kuleuven.be<Herman [dot] Bruyninckx [..] ...>
>> >
>> On Fri, 21 Sep 2012, Willy Lambert wrote:
>>
>> Hi,
>>
>> I would like to do something like a parallel deployment for a
>> bunch of
>> component. That means
>> that I would like to call all "configure" function in
>> parallel without
>> blocking because they are
>> a bit long, and call for all of them component.isConfigured()
>> to check
>> the end of this. This is
>> done in the configureHook of a monitoring component that is
>> responsible
>> to manage all this.
>>
>> Is there anything existing to do this ?
>> Should I use a particular "configure" function or should I
>> spawn one
>> thread by conpoment to
>> configure ?
>>
>>
>> The _logic_ of your deployment should be robust against both modes of
>> deployment.
>>
>> It is, it's a matter of reducing deployment delays
>>
>
> Do you mean that you still have problems in your deployment because of
> delays? In that case, your deployment logic is _not_ robust...
No I mean that configureHook are long (and not consumming all CPU) so I'd
like to have several configureHook running at "the same time". Everything
is fine currently. Thank for wondering anyway.
>
>
> Is there any problem if several threads calls configureHook
>> on the same
>> component ?
>>
>> Oops, that sounds like a design error to me (violating "ownership" of
>> components). But on the other hand, the component implementations should
>> be
>> robust against this. In the context of configuration, this means that each
>> component should keep track of what it has already done wrt configuration.
>> This is also "state", but it makes more sense to keep that state in a data
>> structure instead of putting it into a state machine.
>>
>> Yes, of course, my question is more about Orocos behavior in such
>> situation. if I were using
>> operation as Sylvain suggested I wouldn't have any problem (because I
>> think it is handled), but
>> I don't know what's happening when I'm just using TaskContext.configure()
>> directly in C++. I'm
>> afraid that the Operation call interface is bypassed.
>>
>
> This sounds like a (one of the many...) "semantic variation points" that we
> still have in RTT. I would welcome an overview of all of these, so that we
> can think together about "the" solution to solve them. Because one of the
> worst thing a software framework can have is uncertainty about its
> behavioural model.
>
>
> What's behind this, is that I wait for some hardware
>> synchronisation in
>> configureHook of low
>> level components. I think the real problem is that I use the
>> configureHook that is at framework
>> level instead of a particular running state that would be
>> more a
>> functionnal level. I know this
>> will hurt Hermann (^^)
>>
>> It will not :-) The concept of synchronisation by letting different state
>> machines wait for a set of events is a fine pattern, at any level of
>> "component abstraction".
>>
>> but I'm stucked with this now, and I have no time to change that.
>>
>
> Herman
>
Non blocking configure/start/stop/cleanup function for parallel
On Sep 21, 2012, at 08:56 , Willy Lambert wrote:
>
>
> 2012/9/21 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Fri, 21 Sep 2012, Willy Lambert wrote:
>
>
>
> 2012/9/21 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Fri, 21 Sep 2012, Willy Lambert wrote:
>
> Hi,
>
> I would like to do something like a parallel deployment for a bunch of
> component. That means
> that I would like to call all "configure" function in parallel without
> blocking because they are
> a bit long, and call for all of them component.isConfigured() to check
> the end of this. This is
> done in the configureHook of a monitoring component that is responsible
> to manage all this.
>
> Is there anything existing to do this ?
> Should I use a particular "configure" function or should I spawn one
> thread by conpoment to
> configure ?
>
>
> The _logic_ of your deployment should be robust against both modes of
> deployment.
>
> It is, it's a matter of reducing deployment delays
>
> Do you mean that you still have problems in your deployment because of
> delays? In that case, your deployment logic is _not_ robust...
>
> No I mean that configureHook are long (and not consumming all CPU) so I'd like to have several configureHook running at "the same time". Everything is fine currently. Thank for wondering anyway.
We coordinate using state machines, and don't start the long stuff until the component is actually running. So instead of trying to map the device initialization states onto the configure -> start -> update hooks, we let the component start in essentially an idle state, and then each component's state machine starts the actual long work. An overall system coordinator waits for everything to be ready, before transitioning the system as a whole to a ready state.
HTH
S
Non blocking configure/start/stop/cleanup function for parallel
>>
>> No I mean that configureHook are long (and not consumming all CPU) so
>> I'd like to have several configureHook running at "the same time".
>> Everything is fine currently. Thank for wondering anyway.
>
> We coordinate using state machines, and don't start the long stuff
> until the component is actually running. So instead of trying to map
> the device initialization states onto the configure -> start -> update
> hooks, we let the component start in essentially an idle state, and
> then each component's state machine starts the actual long work. An
> overall system coordinator waits for everything to be ready, before
> transitioning the system as a whole to a ready state.
As always, it is a matter of what the states represent.
In Rock, the STOPPED state means "the component is ready to be started
for processing". This is not the case in your case. Additionally, we
expect configure() to be done in isolation (i.e. don't depend on other
components to run already), which allows for easy parallelization.
Non blocking configure/start/stop/cleanup function for parallel
On Sep 21, 2012, at 10:20 , Sylvain Joyeux wrote:
>
>>>
>>> No I mean that configureHook are long (and not consumming all CPU) so I'd like to have several configureHook running at "the same time". Everything is fine currently. Thank for wondering anyway.
>>
>> We coordinate using state machines, and don't start the long stuff until the component is actually running. So instead of trying to map the device initialization states onto the configure -> start -> update hooks, we let the component start in essentially an idle state, and then each component's state machine starts the actual long work. An overall system coordinator waits for everything to be ready, before transitioning the system as a whole to a ready state.
> As always, it is a matter of what the states represent.
Agreed, I was just giving one example.
> In Rock, the STOPPED state means "the component is ready to be started for processing". This is not the case in your case.
Tomatoe, tomato. Shrug ...
> Additionally, we expect configure() to be done in isolation (i.e. don't depend on other components to run already), which allows for easy parallelization.
Our's parallelizes too.
S
Non blocking configure/start/stop/cleanup function for parallel
On 09/21/2012 04:34 PM, Stephen Roderick wrote:.
>> Additionally, we expect configure() to be done in isolation (i.e. don't depend on other components to run already), which allows for easy parallelization.
> Our's parallelizes too.
What I meant by "simple" is: if configure() is expected to work in
isolation, then there is no ordering needed between the configure steps.
If not, you need to take care of that as well.
Non blocking configure/start/stop/cleanup function for parallel
On 09/21/2012 02:04 PM, Willy Lambert wrote:
>
> Should I use a particular "configure" function or should I spawn one
> thread by conpoment to configure ?
Well, configure() is declared as an operation, so you can use the
asynchronous operation call mechanisms.
> Is there any problem if several threads calls configureHook on the
> same component ?
>
> What's behind this, is that I wait for some hardware synchronisation
> in configureHook of low level components. I think the real problem is
> that I use the configureHook that is at framework level instead of a
> particular running state that would be more a functionnal level. I
> know this will hurt Hermann (^^) but I'm stucked with this now, and I
> have no time to change that.
It does not hurt me. I am pretty fine with that.
Non blocking configure/start/stop/cleanup function for parallel
2012/9/21 S Roderick <kiwi [dot] net [..] ...>
> On Sep 21, 2012, at 08:56 , Willy Lambert wrote:
>
>
>
> 2012/9/21 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
>
>> On Fri, 21 Sep 2012, Willy Lambert wrote:
>>
>>
>>>
>>> 2012/9/21 Herman Bruyninckx <Herman.Bruyninckx@mech.**kuleuven.be<Herman [dot] Bruyninckx [..] ...>
>>> >
>>> On Fri, 21 Sep 2012, Willy Lambert wrote:
>>>
>>> Hi,
>>>
>>> I would like to do something like a parallel deployment for
>>> a bunch of
>>> component. That means
>>> that I would like to call all "configure" function in
>>> parallel without
>>> blocking because they are
>>> a bit long, and call for all of them
>>> component.isConfigured() to check
>>> the end of this. This is
>>> done in the configureHook of a monitoring component that is
>>> responsible
>>> to manage all this.
>>>
>>> Is there anything existing to do this ?
>>> Should I use a particular "configure" function or should I
>>> spawn one
>>> thread by conpoment to
>>> configure ?
>>>
>>>
>>> The _logic_ of your deployment should be robust against both modes of
>>> deployment.
>>>
>>> It is, it's a matter of reducing deployment delays
>>>
>>
>> Do you mean that you still have problems in your deployment because of
>> delays? In that case, your deployment logic is _not_ robust...
>
>
> No I mean that configureHook are long (and not consumming all CPU) so I'd
> like to have several configureHook running at "the same time". Everything
> is fine currently. Thank for wondering anyway.
>
>
> We coordinate using state machines, and don't start the long stuff until
> the component is actually running. So instead of trying to map the device
> initialization states onto the configure -> start -> update hooks, we let
> the component start in essentially an idle state, and then each component's
> state machine starts the actual long work. An overall system coordinator
> waits for everything to be ready, before transitioning the system as a
> whole to a ready state.
>
Yes, I've learned this after having done the core structure. So now it's
quite an heavy work to put all this into a nice design and I'm not willing
to do this for now.
>
> HTH
> S
>
Non blocking configure/start/stop/cleanup function for parallel
2012/9/21 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> On 09/21/2012 02:04 PM, Willy Lambert wrote:
>
>>
>> Should I use a particular "configure" function or should I spawn one
>> thread by conpoment to configure ?
>>
> Well, configure() is declared as an operation, so you can use the
> asynchronous operation call mechanisms.
Damned ! Thanks ! It was so obvious...
>
> Is there any problem if several threads calls configureHook on the same
>> component ?
>>
>> What's behind this, is that I wait for some hardware synchronisation in
>> configureHook of low level components. I think the real problem is that I
>> use the configureHook that is at framework level instead of a particular
>> running state that would be more a functionnal level. I know this will hurt
>> Hermann (^^) but I'm stucked with this now, and I have no time to change
>> that.
>>
> It does not hurt me. I am pretty fine with that.
>
> --
> Sylvain Joyeux (Dr.Ing.)
> Senior Researcher
>
> Space & Security Robotics
> Underwater Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> 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
> ------------------------------**------------------------------**
> -----------
>
>
Non blocking configure/start/stop/cleanup function for parallel
2012/9/21 Willy Lambert <lambert [dot] willy [..] ...>
>
>
>
> 2012/9/21 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>
>> On 09/21/2012 02:04 PM, Willy Lambert wrote:
>>>
>>>
>>> Should I use a particular "configure" function or should I spawn one thread by conpoment to configure ?
>>
>> Well, configure() is declared as an operation, so you can use the asynchronous operation call mechanisms.
>
>
> Damned ! Thanks ! It was so obvious...
It is almost working by now. I would like to add a timeout on the
results polling. I thought that (pseudo code) :
while (handle.collect() == SendNotReady && timeoutIsOk)
timeout++
sleep(1);
will do the job, but the code is blocking on handle.collect(). To
check this I call a configure as an operation on a peer and put
while(1) sleep(1) in the peer's configureHook. Is it a bug or a miss
use of functions ?
for the code above, the documentation invoke collectIfDone() but it
doesn't exist any more.
>
>
>>
>>
>>> Is there any problem if several threads calls configureHook on the same component ?
>>>
>>> What's behind this, is that I wait for some hardware synchronisation in configureHook of low level components. I think the real problem is that I use the configureHook that is at framework level instead of a particular running state that would be more a functionnal level. I know this will hurt Hermann (^^) but I'm stucked with this now, and I have no time to change that.
>>
>> It does not hurt me. I am pretty fine with that.
>>
>> --
>> Sylvain Joyeux (Dr.Ing.)
>> Senior Researcher
>>
>> Space & Security Robotics
>> Underwater Robotics
>>
>> !!! Achtung, neue Telefonnummer!!!
>>
>> Standort Bremen:
>> DFKI GmbH
>> Robotics Innovation Center
>> Robert-Hooke-Straße 5
>> 28359 Bremen, Germany
>>
>> Phone: +49 (0)421 178-454136
>> Fax: +49 (0)421 218-454150
>> E-Mail: robotik [..] ...
>>
>> 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
>> -----------------------------------------------------------------------
>>
>
Non blocking configure/start/stop/cleanup function for parallel
On Fri, Sep 21, 2012 at 5:07 PM, Willy Lambert <lambert [dot] willy [..] ...> wrote:
> 2012/9/21 Willy Lambert <lambert [dot] willy [..] ...>
>>
>>
>>
>> 2012/9/21 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>>
>>> On 09/21/2012 02:04 PM, Willy Lambert wrote:
>>>>
>>>>
>>>> Should I use a particular "configure" function or should I spawn one thread by conpoment to configure ?
>>>
>>> Well, configure() is declared as an operation, so you can use the asynchronous operation call mechanisms.
>>
>>
>> Damned ! Thanks ! It was so obvious...
>
>
> It is almost working by now. I would like to add a timeout on the
> results polling. I thought that (pseudo code) :
>
> while (handle.collect() == SendNotReady && timeoutIsOk)
> timeout++
> sleep(1);
>
> will do the job, but the code is blocking on handle.collect(). To
> check this I call a configure as an operation on a peer and put
> while(1) sleep(1) in the peer's configureHook. Is it a bug or a miss
> use of functions ?
>
>
> for the code above, the documentation invoke collectIfDone() but it
> doesn't exist any more.
If collectIfDone() does not work for you, submit a bug report.
Most likely you used the wrong form of collectIfDone and forgot that
configure() returns a boolean, so you need to write:
bool somebool = false;
// ...
handle.collectIfDone( somebool )
Peter