This discussion was started in another thread (it was an example of a
larger discussion).
I think that it deserves another thread to discuss a couple of
"strange behaviors that I have found.
The source code has been simplified, commented better and updated:
http://www.orocos.org/wiki/rtt/rtt-20/contribute-which-weakness-have-you...
Other users noticed that the problem of single thread arises only in
gnulinux, while it wouldn't in different priorities in the
PeriodicActivity are taken into account.
Because of single thread serialization, something unexpected for the
programmer happens.
1) You expect TaskA to be independent from TaskB, but it isn't. If you
think it is a problem of resources of the computer, change the
activity frequency of 1 of the two tasks.
Suggestion:
A) let the programmer choose if single thread serialization is used or not.
B) keep "1 thread for 1 activity policy" for default. It will help
less experienced user
to avoid common errors (and I think it cover most of the cases).
Experienced user can decide to "unleash" the power of single thread
serialization if they want to.
2) after the "block" for 0.5 seconds, the "lost cycles" are executed
all at once.
In other words, updateHook is called 5 times in a row.
This may have very unpredictable results. It could be desirable for
some applications (filter with data buffer) or catastrophic in other
applications (motion control loop).
Suggestion:
C) let the user decide if the "lost cycles" or the PeriodicActivity
need to be executed later or are definitively lost.
D) make the user aware in the documentation
Davide
single thread serialization (was flexibility vs safety)
> This discussion was started in another thread (it was an example of a
> larger discussion).
>
> I think that it deserves another thread to discuss a couple of
> "strange behaviors that I have found.
>
> The source code has been simplified, commented better and updated:
>
http://www.orocos.org/wiki/rtt/rtt-20/contribute-which-weakness-have-you
-
> detected-rtt/problems-single-thread-serialization
>
> Other users noticed that the problem of single thread arises only in
> gnulinux, while it wouldn't in different priorities in the
> PeriodicActivity are taken into account.
>
> Because of single thread serialization, something unexpected for the
> programmer happens.
>
> 1) You expect TaskA to be independent from TaskB, but it isn't. If you
> think it is a problem of resources of the computer, change the
> activity frequency of 1 of the two tasks.
>
On my os I _do_ get two threads. So the "default single thread
serialization" you speak of is merely a bug in the os-abstraction layer
RTT is using (in this case gnulinux apparently).
> Suggestion:
> A) let the programmer choose if single thread serialization is used or
> not.
Not needed, fix the bug in os-abstraction. This choice can already be
made by giving a priority in the creation of PeriodicThread.
> B) keep "1 thread for 1 activity policy" for default. It will help
> less experienced user
> to avoid common errors (and I think it cover most of the cases).
> Experienced user can decide to "unleash" the power of single thread
> serialization if they want to.
We don't want this, we share one thread for multiple activities.
Because:
A) We don't have Mbytes to spare (actually we have 1.)
B) We have a limited amount of "threads".
>
> 2) after the "block" for 0.5 seconds, the "lost cycles" are executed
> all at once.
> In other words, updateHook is called 5 times in a row.
> This may have very unpredictable results. It could be desirable for
> some applications (filter with data buffer) or catastrophic in other
> applications (motion control loop).
>
> Suggestion:
> C) let the user decide if the "lost cycles" or the PeriodicActivity
> need to be executed later or are definitively lost.
> D) make the user aware in the documentation
>
This is depended on the type of os used. In an RTOS the controller
should halt or generate some kind of emergency stop. After all, a
deadline is not met! In our case for example it is possible that there
is already a mechanical malfunction. So what's the point of continuing
or recovering in this case?
On a general purpose os hiccups are "normal" so this case will occur
sooner or later, with or without bad application design.
I'm not even sure RTT should deal with this. It is OS depended.
Sander.
single thread serialization (was flexibility vs safety)
On Mon, May 04, 2009 at 09:25:26AM +0200, Vandenbroucke Sander wrote:
> > This discussion was started in another thread (it was an example of a
> > larger discussion).
> >
> > I think that it deserves another thread to discuss a couple of
> > "strange behaviors that I have found.
> >
> > The source code has been simplified, commented better and updated:
> >
> http://www.orocos.org/wiki/rtt/rtt-20/contribute-which-weakness-have-you
> -
> > detected-rtt/problems-single-thread-serialization
> >
> > Other users noticed that the problem of single thread arises only in
> > gnulinux, while it wouldn't in different priorities in the
> > PeriodicActivity are taken into account.
> >
> > Because of single thread serialization, something unexpected for the
> > programmer happens.
> >
> > 1) You expect TaskA to be independent from TaskB, but it isn't. If you
> > think it is a problem of resources of the computer, change the
> > activity frequency of 1 of the two tasks.
> >
> On my os I _do_ get two threads. So the "default single thread
> serialization" you speak of is merely a bug in the os-abstraction layer
> RTT is using (in this case gnulinux apparently).
>
> > Suggestion:
> > A) let the programmer choose if single thread serialization is used or
> > not.
> Not needed, fix the bug in os-abstraction. This choice can already be
> made by giving a priority in the creation of PeriodicThread.
Yes, but this is _ugly_! Fiddling with thread priorities to influence
how the RTT sets up the execution of components seems really wrong. I
would prefer to make this explicit as Davide suggested.
But defining what is default is tough. Maybe something like
"deployment profiles" could help, e.g. allow to choose between
- robustness: components get their own thread or process by default
- latency: components are serialized by default
...
> > B) keep "1 thread for 1 activity policy" for default. It will help
> > less experienced user
> > to avoid common errors (and I think it cover most of the cases).
> > Experienced user can decide to "unleash" the power of single thread
> > serialization if they want to.
> We don't want this, we share one thread for multiple activities.
> Because:
> A) We don't have Mbytes to spare (actually we have 1.)
> B) We have a limited amount of "threads".
Yes, of course this is a valid use case.
> > 2) after the "block" for 0.5 seconds, the "lost cycles" are executed
> > all at once.
> > In other words, updateHook is called 5 times in a row.
> > This may have very unpredictable results. It could be desirable for
> > some applications (filter with data buffer) or catastrophic in other
> > applications (motion control loop).
> >
> > Suggestion:
> > C) let the user decide if the "lost cycles" or the PeriodicActivity
> > need to be executed later or are definitively lost.
> > D) make the user aware in the documentation
> >
> This is depended on the type of os used. In an RTOS the controller
I would say it should depend on the application, not the OS.
> should halt or generate some kind of emergency stop. After all, a
> deadline is not met! In our case for example it is possible that there
> is already a mechanical malfunction. So what's the point of continuing
> or recovering in this case?
Maybe... but maybe recovery is possible? This depends on the
application. I agree that simply stopping might be a good default,
unless the user *configures* one of the other behaviors.
> On a general purpose os hiccups are "normal" so this case will occur
> sooner or later, with or without bad application design.
>
> I'm not even sure RTT should deal with this. It is OS depended.
It is influenced by the OS of course, but it is the task of the RTT to
smooth out these kind of issues.
Markus
single thread serialization (was flexibility vssafety)
> >
> > > Suggestion:
> > > A) let the programmer choose if single thread serialization is
used or
> > > not.
> > Not needed, fix the bug in os-abstraction. This choice can already
be
> > made by giving a priority in the creation of PeriodicThread.
>
> Yes, but this is _ugly_! Fiddling with thread priorities to influence
> how the RTT sets up the execution of components seems really wrong. I
> would prefer to make this explicit as Davide suggested.
>
Then how do you suggest the set-up of execution of components?
> But defining what is default is tough. Maybe something like
> "deployment profiles" could help, e.g. allow to choose between
>
What is what though? I didn't get this.
> - robustness: components get their own thread or process by default
> - latency: components are serialized by default
> ...
Didn't you mix up robustness with latency here? If I want low latency I
put it in a high priority thread(== scheduler executes this thread
before anything else, except for ISR&DSR). But that's only me talking of
course.
>
> > > B) keep "1 thread for 1 activity policy" for default. It will help
> > > less experienced user
> > > to avoid common errors (and I think it cover most of the cases).
> > > Experienced user can decide to "unleash" the power of single
thread
> > > serialization if they want to.
> > We don't want this, we share one thread for multiple activities.
> > Because:
> > A) We don't have Mbytes to spare (actually we have 1.)
> > B) We have a limited amount of "threads".
>
> Yes, of course this is a valid use case.
>
> > > 2) after the "block" for 0.5 seconds, the "lost cycles" are
executed
> > > all at once.
> > > In other words, updateHook is called 5 times in a row.
> > > This may have very unpredictable results. It could be desirable
for
> > > some applications (filter with data buffer) or catastrophic in
other
> > > applications (motion control loop).
> > >
> > > Suggestion:
> > > C) let the user decide if the "lost cycles" or the
PeriodicActivity
> > > need to be executed later or are definitively lost.
> > > D) make the user aware in the documentation
> > >
> > This is depended on the type of os used. In an RTOS the controller
>
> I would say it should depend on the application, not the OS.
>
> > should halt or generate some kind of emergency stop. After all, a
> > deadline is not met! In our case for example it is possible that
there
> > is already a mechanical malfunction. So what's the point of
continuing
> > or recovering in this case?
>
> Maybe... but maybe recovery is possible? This depends on the
> application. I agree that simply stopping might be a good default,
> unless the user *configures* one of the other behaviors.
>
> > On a general purpose os hiccups are "normal" so this case will occur
> > sooner or later, with or without bad application design.
> >
> > I'm not even sure RTT should deal with this. It is OS depended.
>
> It is influenced by the OS of course, but it is the task of the RTT to
> smooth out these kind of issues.
>
I agree maybe I took a too short short-cut to state it is OS-depended.
It depends on how critical a dead-line is. In real life stopping the
controller would be the best thing to do ;-).
Sander.
single thread serialization (was flexibility vssafety)
On Mon, May 04, 2009 at 11:59:02AM +0200, Vandenbroucke Sander wrote:
> > >
> > > > Suggestion:
> > > > A) let the programmer choose if single thread serialization is
> used or
> > > > not.
> > > Not needed, fix the bug in os-abstraction. This choice can already
> be
> > > made by giving a priority in the creation of PeriodicThread.
> >
> > Yes, but this is _ugly_! Fiddling with thread priorities to influence
> > how the RTT sets up the execution of components seems really wrong. I
> > would prefer to make this explicit as Davide suggested.
> >
> Then how do you suggest the set-up of execution of components?
During deployment/configuration you can set a flag (thread_serialized,
thread, process) if you are not happy with the default.
This is really not a big deal I think, just
> > But defining what is default is tough. Maybe something like
> > "deployment profiles" could help, e.g. allow to choose between
> >
> What is what though? I didn't get this.
Tough as in "difficult", not "though".
> > - robustness: components get their own thread or process by default
> > - latency: components are serialized by default
> > ...
> Didn't you mix up robustness with latency here? If I want low latency I
> put it in a high priority thread(== scheduler executes this thread
> before anything else, except for ISR&DSR). But that's only me talking of
> course.
You're right, maybe I should have written jitter instead of latency. I
just meant to point out that such profiles might be more realistic
than finding appropriate defaults for all settings.
> > > On a general purpose os hiccups are "normal" so this case will occur
> > > sooner or later, with or without bad application design.
> > >
> > > I'm not even sure RTT should deal with this. It is OS depended.
> >
> > It is influenced by the OS of course, but it is the task of the RTT to
> > smooth out these kind of issues.
> >
> I agree maybe I took a too short short-cut to state it is OS-depended.
> It depends on how critical a dead-line is. In real life stopping the
> controller would be the best thing to do ;-).
Agreed.
Markus
single thread serialization (was flexibility vs safety)
> On my os I _do_ get two threads. So the "default single thread
> serialization" you speak of is merely a bug in the os-abstraction layer
> RTT is using (in this case gnulinux apparently).
>
I am glad that it is a bug!
>
> > B) keep "1 thread for 1 activity policy" for default. It will help
> > less experienced user
> > to avoid common errors (and I think it cover most of the cases).
> > Experienced user can decide to "unleash" the power of single thread
> > serialization if they want to.
>
> We don't want this, we share one thread for multiple activities.
> Because:
> A) We don't have Mbytes to spare (actually we have 1.)
> B) We have a limited amount of "threads".
>
Well, as Herman would say, we should not generalize the individual needs.
In your case optimization of resources is more important.
I still think that the option should be given to the user.
But, having a default value, we "mask" the complexity to new users,
leaving many options to experienced users.
> >
> > 2) after the "block" for 0.5 seconds, the "lost cycles" are executed
> > all at once.
> > In other words, updateHook is called 5 times in a row.
> > This may have very unpredictable results. It could be desirable for
> > some applications (filter with data buffer) or catastrophic in other
> > applications (motion control loop).
> >
> > Suggestion:
> > C) let the user decide if the "lost cycles" or the PeriodicActivity
> > need to be executed later or are definitively lost.
> > D) make the user aware in the documentation
> >
>
> This is depended on the type of os used. In an RTOS the controller
> should halt or generate some kind of emergency stop. After all, a
> deadline is not met! In our case for example it is possible that there
> is already a mechanical malfunction. So what's the point of continuing
> or recovering in this case?
>
One more time, this is up to the user's applications.
My system can "survive" well to a single deadline missed. I don't want
the controller to halt (my robot is walking, I can't stop it in the
middle of a step!).
What I learned on this forum is that we should not generalize our needs.
Therefore, I guess the best is to make the user AWARE of this deadline
missed and let him/her decide what is the policy to use to react:
A) do missed loops
B) forget missed loop
C halt the controller
>
> I'm not even sure RTT should deal with this. It is OS depended.
>
I agree: but at this moment RTT is implicitly taking the action A)
It is OS dependent AND application dependent.
Davide
single thread serialization (was flexibility vs safety)
On Mon, 4 May 2009, Davide Faconti wrote:
>> On my os I _do_ get two threads. So the "default single thread
>> serialization" you speak of is merely a bug in the os-abstraction layer
>> RTT is using (in this case gnulinux apparently).
>
> I am glad that it is a bug!
Actually, I think it is a documented feature.
AFAIK (please prove me wrong) the documentation mentions the fact that:
- when you run your orocos application on a (non-realtime) scheduler that does not offer multiple static priorities (ic. gnulinux)
applications your given priorities
Moreover, orocos warns you in this case
[kgad@ampere /tmp]$
export PATH=/kgad/install/orocos/1.6/bin/:$PATH
[kgad@ampere /tmp]$
export LD_LIBRARY_PATH=/kgad/install/orocos/1.6/lib/
[kgad@ampere /tmp]$
./a.out
0.005 [ Warning][./a.out::main()] Lowering scheduler type to SCHED_OTHER for non-privileged users..
0.005 [ Warning][./a.out::main()] Forcing priority (1) of thread with SCHED_OTHER policy to 0.
0.007 [ Warning][./a.out::main()] Lowering scheduler type to SCHED_OTHER for non-privileged users..
0.007 [ Warning][./a.out::main()] Forcing priority (2) of thread with SCHED_OTHER policy to 0.
Note that the gnulinux target was originally meant for debugging purposes only. This might (and maybe should be) reconsidered in the light of the recent PREEMPT_RT
- when you have two activities with the same priority (and if periodic also the period), they will be serialized in a single thread.
So I don't agree this is a bug. However, your application for me clearly reveals that
1/ There is a problem with the documentation
2/ That the fact that activities with same period/priority are "by default" serialized in a single thread is introducing policy into the RTT, which is not a good thing. And that we should "optionise" this policy (and clearly document what the consequences of a certain policy are) for 2.0.
>> > B) keep "1 thread for 1 activity policy" for default. It will help
>> > less experienced user
>> > to avoid common errors (and I think it cover most of the cases).
>> > Experienced user can decide to "unleash" the power of single thread
>> > serialization if they want to.
>>
>> We don't want this, we share one thread for multiple activities.
>> Because:
>> A) We don't have Mbytes to spare (actually we have 1.)
>> B) We have a limited amount of "threads".
>>
>
> Well, as Herman would say, we should not generalize the individual needs.
> In your case optimization of resources is more important.
> I still think that the option should be given to the user.
> But, having a default value, we "mask" the complexity to new users,
> leaving many options to experienced users.
OK, should have read the whole post first. For the "monday morning reader", this is what I meant in point 2/ above :-)
>> > 2) after the "block" for 0.5 seconds, the "lost cycles" are executed
>> > all at once.
>> > In other words, updateHook is called 5 times in a row.
>> > This may have very unpredictable results. It could be desirable for
>> > some applications (filter with data buffer) or catastrophic in other
>> > applications (motion control loop).
>> >
>> > Suggestion:
>> > C) let the user decide if the "lost cycles" or the PeriodicActivity
>> > need to be executed later or are definitively lost.
>> > D) make the user aware in the documentation
>> >
>>
>> This is depended on the type of os used. In an RTOS the controller
>> should halt or generate some kind of emergency stop. After all, a
>> deadline is not met! In our case for example it is possible that there
>> is already a mechanical malfunction. So what's the point of continuing
>> or recovering in this case?
>>
>
> One more time, this is up to the user's applications.
> My system can "survive" well to a single deadline missed. I don't want
> the controller to halt (my robot is walking, I can't stop it in the
> middle of a step!).
> What I learned on this forum is that we should not generalize our needs.
> Therefore, I guess the best is to make the user AWARE of this deadline
> missed and let him/her decide what is the policy to use to react:
>
> A) do missed loops
> B) forget missed loop
> C halt the controller
>
>>
>> I'm not even sure RTT should deal with this. It is OS depended.
>>
> I agree: but at this moment RTT is implicitly taking the action A)
> It is OS dependent AND application dependent.
>
> Davide
>
single thread serialization (was flexibility vs safety)
On Mon, May 04, 2009 at 10:50:47AM +0200, Klaas Gadeyne wrote:
> On Mon, 4 May 2009, Davide Faconti wrote:
> >> On my os I _do_ get two threads. So the "default single thread
> >> serialization" you speak of is merely a bug in the os-abstraction layer
> >> RTT is using (in this case gnulinux apparently).
> >
> > I am glad that it is a bug!
>
> Actually, I think it is a documented feature.
> AFAIK (please prove me wrong) the documentation mentions the fact that:
> - when you run your orocos application on a (non-realtime) scheduler that does not offer multiple static priorities (ic. gnulinux)
> applications your given priorities
>
> Moreover, orocos warns you in this case
>
> [kgad@ampere /tmp]$
> export PATH=/kgad/install/orocos/1.6/bin/:$PATH
> [kgad@ampere /tmp]$
> export LD_LIBRARY_PATH=/kgad/install/orocos/1.6/lib/
> [kgad@ampere /tmp]$
> ./a.out
> 0.005 [ Warning][./a.out::main()] Lowering scheduler type to SCHED_OTHER for non-privileged users..
> 0.005 [ Warning][./a.out::main()] Forcing priority (1) of thread with SCHED_OTHER policy to 0.
> 0.007 [ Warning][./a.out::main()] Lowering scheduler type to SCHED_OTHER for non-privileged users..
> 0.007 [ Warning][./a.out::main()] Forcing priority (2) of thread with SCHED_OTHER policy to 0.
This is what matters really.
> Note that the gnulinux target was originally meant for debugging
I didn't know this.
> purposes only. This might (and maybe should be) reconsidered in
> the light of the recent PREEMPT_RT
Indeed... in fact if the RTT is built on top of the Xenomai POSIX skin
(is it?) the differences should be quite small...
Markus
single thread serialization (was flexibility vs safety)
On May 4, 2009, at 05:11 , Markus Klotzb=FCcher wrote:
> On Mon, May 04, 2009 at 10:50:47AM +0200, Klaas Gadeyne wrote:
>> On Mon, 4 May 2009, Davide Faconti wrote:
>>>> On my os I _do_ get two threads. So the "default single thread
>>>> serialization" you speak of is merely a bug in the os-abstraction
>>>> layer
>>>> RTT is using (in this case gnulinux apparently).
>>>
>>> I am glad that it is a bug!
>>
>> Actually, I think it is a documented feature.
>> AFAIK (please prove me wrong) the documentation mentions the fact
>> that:
>> - when you run your orocos application on a (non-realtime)
>> scheduler that does not offer multiple static priorities (ic.
>> gnulinux)
>> applications your given priorities
>>
>> Moreover, orocos warns you in this case
>>
>> [kgad@ampere /tmp]$
>> export PATH=/kgad/install/orocos/1.6/bin/:$PATH
>> [kgad@ampere /tmp]$
>> export LD_LIBRARY_PATH=/kgad/install/orocos/1.6/lib/
>> [kgad@ampere /tmp]$
>> ./a.out
>> 0.005 [ Warning][./a.out::main()] Lowering scheduler type to
>> SCHED_OTHER for non-privileged users..
>> 0.005 [ Warning][./a.out::main()] Forcing priority (1) of thread
>> with SCHED_OTHER policy to 0.
>> 0.007 [ Warning][./a.out::main()] Lowering scheduler type to
>> SCHED_OTHER for non-privileged users..
>> 0.007 [ Warning][./a.out::main()] Forcing priority (2) of thread
>> with SCHED_OTHER policy to 0.
>
> This is what matters really.
>
>> Note that the gnulinux target was originally meant for debugging
>
> I didn't know this.
>
>> purposes only. This might (and maybe should be) reconsidered in
>> the light of the recent PREEMPT_RT
>
> Indeed... in fact if the RTT is built on top of the Xenomai POSIX skin
> (is it?) the differences should be quite small...
We already support PREEMPT_RT IIRC. Just set a component's priority in
gnulinux, and you'll find it uses the posix calls to push the
component into real-time. Like I said ... IIRC
S
single thread serialization (was flexibility vs safety)
[apologies for possible multiple postings, my 'alpine' mailclient does not like umlauts it seems]
On Mon, 4 May 2009, Markus Klotzb??wrote:
> On Mon, May 04, 2009 at 10:50:47AM +0200, Klaas Gadeyne wrote:
>> On Mon, 4 May 2009, Davide Faconti wrote:
>>>> On my os I _do_ get two threads. So the "default single thread
>>>> serialization" you speak of is merely a bug in the os-abstraction layer
>>>> RTT is using (in this case gnulinux apparently).
>>>
>>> I am glad that it is a bug!
>>
>> Actually, I think it is a documented feature.
>> AFAIK (please prove me wrong) the documentation mentions the fact that:
>> - when you run your orocos application on a (non-realtime) scheduler that does not offer multiple static priorities (ic. gnulinux)
>> applications your given priorities
>>
>> Moreover, orocos warns you in this case
>>
>> [kgad@ampere /tmp]$
>> export PATH=/kgad/install/orocos/1.6/bin/:$PATH
>> [kgad@ampere /tmp]$
>> export LD_LIBRARY_PATH=/kgad/install/orocos/1.6/lib/
>> [kgad@ampere /tmp]$
>> ./a.out
>> 0.005 [ Warning][./a.out::main()] Lowering scheduler type to SCHED_OTHER for non-privileged users..
>> 0.005 [ Warning][./a.out::main()] Forcing priority (1) of thread with SCHED_OTHER policy to 0.
>> 0.007 [ Warning][./a.out::main()] Lowering scheduler type to SCHED_OTHER for non-privileged users..
>> 0.007 [ Warning][./a.out::main()] Forcing priority (2) of thread with SCHED_OTHER policy to 0.
>
> This is what matters really.
Also note (maybe I did not stress this enough) that this also only occurs because you're not running your application as su
[kgad@ampere /tmp]$
sudo LD_LIBRARY_PATH=/kgad/install/orocos/1.6/lib/ ./a.out
Provider [0.00] Loop
User [0.01] Loop
Provider [0.50] Loop
User [0.51] Loop
Provider [1.00] Loop
User [1.01] Loop
Provider [1.50] Loop
User [1.51] Loop
Provider [2.00] Loop
User [2.01] Loop
User [2.01] before calling the method
Provider [2.01] Executing the method callback
Provider [2.50] Loop
Provider [3.00] Loop
Provider [3.50] Loop
Provider [4.00] Loop
Provider [4.01] I have finished
User [4.01] after calling the method
User [4.01] Loop
User [4.01] Loop
User [4.01] Loop
User [4.01] Loop
Provider [4.50] Loop
User [4.51] Loop
User [4.51] before calling the method
Provider [4.51] Executing the method callback
Provider [5.00] Loop
Provider [5.50] Loop
Provider [6.00] Loop
Provider [6.50] Loop
Provider [6.51] I have finished
User [6.51] after calling the method
User [6.51] Loop
User [6.51] Loop
User [6.51] Loop
User [6.51] Loop
Provider [7.00] Loop
User [7.01] Loop
User [7.01] before calling the method
Provider [7.01] Executing the method callback
Provider [7.50] Loop
Note that in this case the "User" (not the provider) still misses deadlines. IMO, one could consider this as "bad component design". The documentation of Provider::Method() should explicitly mention that the method will take 2 secs for execution.
>> Note that the gnulinux target was originally meant for debugging
>
> I didn't know this.
Well, it is somehow mentioned (http://people.mech.kuleuven.be/~orocos/pub/stable/documentation/rtt/curr...), and you maybe should have wondered how on earth is it possible to run the _real-time_ toolkit on a _non-realtime_ OS :-)
>> purposes only. This might (and maybe should be) reconsidered in
>> the light of the recent PREEMPT_RT
>
> Indeed... in fact if the RTT is built on top of the Xenomai POSIX skin
> (is it?) the differences should be quite small...
Is is not. RTT has mappings for each OS, so if you are using the gnulinux target, you (should normally) get the added benefits of RT_PREEMPT for free.
Klaas
single thread serialization (was flexibility vs safety)
> Note that in this case the "User" (not the provider) still misses deadlines. IMO, one could consider this as "bad component design". The documentation of Provider::Method() should explicitly mention that the method will take 2 secs for execution.
>
Exactly, the example is INTENTIONALLY about a user with a bad component design.
The goal is to demonstrate that if User is a bad component and
Provider is not, the only affected is User (of course, if Provider
DONT use the interface of User).
>
>
> Well, it is somehow mentioned (http://people.mech.kuleuven.be/~orocos/pub/stable/documentation/rtt/curr...), and you maybe should have wondered how on earth is it possible to run the _real-time_ toolkit on a _non-realtime_ OS :-)
>
>
I would like to spend just one word about it. I really believe that
RTT should work correctly on gnulinux and we a valuable tools for
people which don't need real-time, but a toolkit which save them a lot
of design time and make components reusable.
It would be a strategical error to focus RTT on hard real time only.
single thread serialization (was flexibility vs safety)
> -----Original Message-----
> From: orocos-dev-bounces [..] ... [mailto:orocos-dev-
> bounces [..] ...] On Behalf Of Klaas Gadeyne
> Sent: maandag 4 mei 2009 11:31
> To: orocos-dev [..] ...
> Subject: Re: [Orocos-Dev] single thread serialization (was flexibility
vs
> safety)
>
> [apologies for possible multiple postings, my 'alpine' mailclient does
not
> like umlauts it seems]
>
> On Mon, 4 May 2009, Markus Klotzb??wrote:
> > On Mon, May 04, 2009 at 10:50:47AM +0200, Klaas Gadeyne wrote:
> >> On Mon, 4 May 2009, Davide Faconti wrote:
> >>>> On my os I _do_ get two threads. So the "default single thread
> >>>> serialization" you speak of is merely a bug in the
os-abstraction
> layer
> >>>> RTT is using (in this case gnulinux apparently).
> >>>
> >>> I am glad that it is a bug!
> >>
> >> Actually, I think it is a documented feature.
> >> AFAIK (please prove me wrong) the documentation mentions the fact
that:
> >> - when you run your orocos application on a (non-realtime)
scheduler
> that does not offer multiple static priorities (ic. gnulinux)
> >> applications your given priorities
> >>
> >> Moreover, orocos warns you in this case
> >>
> >> [kgad@ampere /tmp]$
> >> export PATH=/kgad/install/orocos/1.6/bin/:$PATH
> >> [kgad@ampere /tmp]$
> >> export LD_LIBRARY_PATH=/kgad/install/orocos/1.6/lib/
> >> [kgad@ampere /tmp]$
> >> ./a.out
> >> 0.005 [ Warning][./a.out::main()] Lowering scheduler type to
> SCHED_OTHER for non-privileged users..
> >> 0.005 [ Warning][./a.out::main()] Forcing priority (1) of thread
> with SCHED_OTHER policy to 0.
> >> 0.007 [ Warning][./a.out::main()] Lowering scheduler type to
> SCHED_OTHER for non-privileged users..
> >> 0.007 [ Warning][./a.out::main()] Forcing priority (2) of thread
> with SCHED_OTHER policy to 0.
> >
> > This is what matters really.
>
> Also note (maybe I did not stress this enough) that this also only
occurs
> because you're not running your application as su
>
> [kgad@ampere /tmp]$
> sudo LD_LIBRARY_PATH=/kgad/install/orocos/1.6/lib/ ./a.out
> Provider [0.00] Loop
> User [0.01] Loop
> Provider [0.50] Loop
> User [0.51] Loop
> Provider [1.00] Loop
> User [1.01] Loop
> Provider [1.50] Loop
> User [1.51] Loop
> Provider [2.00] Loop
> User [2.01] Loop
> User [2.01] before calling the method
> Provider [2.01] Executing the method callback
> Provider [2.50] Loop
> Provider [3.00] Loop
> Provider [3.50] Loop
> Provider [4.00] Loop
> Provider [4.01] I have finished
> User [4.01] after calling the method
> User [4.01] Loop
> User [4.01] Loop
> User [4.01] Loop
> User [4.01] Loop
> Provider [4.50] Loop
> User [4.51] Loop
> User [4.51] before calling the method
> Provider [4.51] Executing the method callback
> Provider [5.00] Loop
> Provider [5.50] Loop
> Provider [6.00] Loop
> Provider [6.50] Loop
> Provider [6.51] I have finished
> User [6.51] after calling the method
> User [6.51] Loop
> User [6.51] Loop
> User [6.51] Loop
> User [6.51] Loop
> Provider [7.00] Loop
> User [7.01] Loop
> User [7.01] before calling the method
> Provider [7.01] Executing the method callback
> Provider [7.50] Loop
>
> Note that in this case the "User" (not the provider) still misses
> deadlines. IMO, one could consider this as "bad component design".
The
> documentation of Provider::Method() should explicitly mention that the
> method will take 2 secs for execution.
>
> >> Note that the gnulinux target was originally meant for debugging
> >
> > I didn't know this.
>
> Well, it is somehow mentioned
>
(http://people.mech.kuleuven.be/~orocos/pub/stable/documentation/rtt/cur
re
> nt/doc-xml/orocos-installation.html#setup_intro), and you maybe should
> have wondered how on earth is it possible to run the _real-time_
toolkit
> on a _non-realtime_ OS :-)
>
> >> purposes only. This might (and maybe should be) reconsidered in
> >> the light of the recent PREEMPT_RT
> >
> > Indeed... in fact if the RTT is built on top of the Xenomai POSIX
skin
> > (is it?) the differences should be quite small...
>
> Is is not. RTT has mappings for each OS, so if you are using the
gnulinux
> target, you (should normally) get the added benefits of RT_PREEMPT for
> free.
>
> Klaas
>
So basically nothing is wrong with RTT (except for documentation) on
this issue, it is just how the user uses it that is wrong.
Sander.
single thread serialization (was flexibility vs safety)
Sander and Klaas,
you are right! The error was mine. Running the example with sudo the
example works correctly.
I will remove the source code from the wiki.
Thanks
Davide
single thread serialization (was flexibility vs safety)
On Mon, May 4, 2009 at 1:21 PM, Davide Faconti <faconti [..] ...> wrote:
> Sander and Klaas,
>
> you are right! The error was mine. Running the example with sudo the
> example works correctly.
Maybe I've should have mentioned the sudo thing earlier (I thought
that you knew that since you posted the code).
> I will remove the source code from the wiki.
I would leave it there, and point to this email-discussion.
My conclusion is still that single thread scenario should become
optional. You could easily rewrite your example with 2 components and
an updateHook with a "sleep(2)" loop. Admitted, this would be very
stupid to do, but it could be useful documentation to show new users
possible effects of STS.
The second conclusion is: never ignore orocos warnings in vain :-)
And now get some real work done :-)
Klaas
single thread serialization (was flexibility vs safety)
On May 4, 2009, at 07:28 , Klaas Gadeyne wrote:
> On Mon, May 4, 2009 at 1:21 PM, Davide Faconti <faconti [..] ...
> > wrote:
>> Sander and Klaas,
>>
>> you are right! The error was mine. Running the example with sudo the
>> example works correctly.
>
> Maybe I've should have mentioned the sudo thing earlier (I thought
> that you knew that since you posted the code).
This is one of the "intended for the FAQ" entries. Also, you don't
need sudo if you set the PAM security limits correctly (/etc/security/
limits.conf and ulimit -r ...)
S
single thread serialization (was flexibility vs safety)
On Mon, 4 May 2009, Vandenbroucke Sander wrote:
> So basically nothing is wrong with RTT (except for documentation) on
> this issue, it is just how the user uses it that is wrong.
Well (to repeat myself), I still think the "thread serialization" feature should become optional.
As a side note: I think this example has been _very_ useful to be able to discuss about RTT without falling into what I would call "high-level false-true" discussions (thank you Davide). And I think it's a good way to discuss RTT 2.0 issues on this level, because (given the lack of using diagrams :-) currently the code is the only thing which has a clear semantics.
Klaas
single thread serialization (was flexibility vs safety)
Thanks to Davide for raising this issue:
On Mon, May 4, 2009 at 11:50 AM, Klaas Gadeyne <klaas [dot] gadeyne [..] ...>wrote:
> On Mon, 4 May 2009, Vandenbroucke Sander wrote:
> > So basically nothing is wrong with RTT (except for documentation) on
> > this issue, it is just how the user uses it that is wrong.
>
> Well (to repeat myself), I still think the "thread serialization" feature
> should become optional.
>
> As a side note: I think this example has been _very_ useful to be able to
> discuss about RTT without falling into what I would call "high-level
> false-true" discussions (thank you Davide). And I think it's a good way to
> discuss RTT 2.0 issues on this level, because (given the lack of using
> diagrams :-) currently the code is the only thing which has a clear
> semantics.
>
I agree with all conclusions of this conclusions (I knew you wouldn't need
me, except for coding )
My conclusions for RTT 2.0:
* 1 activity = 1 thread by default (this is actually very logical for new
users and in comparison to other frameworks)
* Serialisation is an execution model, like in 'process', 'thread',
'serialized thread', 'sequential'
It should be specified during deployment (ie during activity attachment to
the component)
* This is a FAQ item today, but could be of lesser importance once the
default is changed
Peter
single thread serialization (was flexibility vs safety)
________________________________
From: peter [dot] soetens [..] ... [mailto:peter [dot] soetens [..] ...] On Behalf
Of Peter Soetens
Sent: donderdag 7 mei 2009 22:06
To: Klaas Gadeyne
Cc: Vandenbroucke Sander; orocos-dev [..] ...
Subject: Re: [Orocos-Dev] single thread serialization (was flexibility
vs safety)
Thanks to Davide for raising this issue:
On Mon, May 4, 2009 at 11:50 AM, Klaas Gadeyne <klaas [dot] gadeyne [..] ...>
wrote:
On Mon, 4 May 2009, Vandenbroucke Sander wrote:
> So basically nothing is wrong with RTT (except for documentation) on
> this issue, it is just how the user uses it that is wrong.
Well (to repeat myself), I still think the "thread serialization"
feature should become optional.
As a side note: I think this example has been _very_ useful to be able
to discuss about RTT without falling into what I would call "high-level
false-true" discussions (thank you Davide). And I think it's a good way
to discuss RTT 2.0 issues on this level, because (given the lack of
using diagrams :-) currently the code is the only thing which has a
clear semantics.
I agree with all conclusions of this conclusions (I knew you wouldn't
need me, except for coding )
My conclusions for RTT 2.0:
* 1 activity = 1 thread by default (this is actually very logical for
new users and in comparison to other frameworks)
True on a P4 running RTLinux with 'endless' resources. For me this model
is useless, so there has to be an alternative.
* Serialisation is an execution model, like in 'process', 'thread',
'serialized thread', 'sequential'
It should be specified during deployment (ie during activity attachment
to the component)
We attach an ExecutionEngine to a component. How the EE's are executed
is defined elsewhere. This has to be possible.
* This is a FAQ item today, but could be of lesser importance once the
default is changed
Peter
__________________________________________________________________
This email has been scanned by the Email Security System.
______________________________________________________________________
single thread serialization (was flexibility vs safety)
________________________________
From: peter [dot] soetens [..] ... [mailto:peter [dot] soetens [..] ...] On Behalf
Of Peter Soetens
Sent: donderdag 7 mei 2009 22:06
To: Klaas Gadeyne
Cc: Vandenbroucke Sander; orocos-dev [..] ...
Subject: Re: [Orocos-Dev] single thread serialization (was flexibility
vs safety)
Thanks to Davide for raising this issue:
On Mon, May 4, 2009 at 11:50 AM, Klaas Gadeyne <klaas [dot] gadeyne [..] ...>
wrote:
On Mon, 4 May 2009, Vandenbroucke Sander wrote:
> So basically nothing is wrong with RTT (except for documentation) on
> this issue, it is just how the user uses it that is wrong.
Well (to repeat myself), I still think the "thread serialization"
feature should become optional.
As a side note: I think this example has been _very_ useful to be able
to discuss about RTT without falling into what I would call "high-level
false-true" discussions (thank you Davide). And I think it's a good way
to discuss RTT 2.0 issues on this level, because (given the lack of
using diagrams :-) currently the code is the only thing which has a
clear semantics.
I agree with all conclusions of this conclusions (I knew you wouldn't
need me, except for coding )
My conclusions for RTT 2.0:
* 1 activity = 1 thread by default (this is actually very logical for
new users and in comparison to other frameworks)
True on a P4 running RTLinux with 'endless' resources. For me this model
is useless, so there has to be an alternative.
* Serialisation is an execution model, like in 'process', 'thread',
'serialized thread', 'sequential'
It should be specified during deployment (ie during activity attachment
to the component)
We attach an ExecutionEngine to a component. How the EE's are executed
is defined elsewhere. This has to be possible.
* This is a FAQ item today, but could be of lesser importance once the
default is changed
Peter
__________________________________________________________________
This email has been scanned by the Email Security System.
______________________________________________________________________
single thread serialization (was flexibility vs safety)
On Thu, May 07, 2009 at 10:06:08PM +0200, Peter Soetens wrote:
> Thanks to Davide for raising this issue:
>
> On Mon, May 4, 2009 at 11:50 AM, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>
> On Mon, 4 May 2009, Vandenbroucke Sander wrote:
> > So basically nothing is wrong with RTT (except for documentation) on
> > this issue, it is just how the user uses it that is wrong.
>
> Well (to repeat myself), I still think the "thread serialization" feature
> should become optional.
>
> As a side note: I think this example has been _very_ useful to be able to
> discuss about RTT without falling into what I would call "high-level
> false-true" discussions (thank you Davide). And I think it's a good way to
> discuss RTT 2.0 issues on this level, because (given the lack of using
> diagrams :-) currently the code is the only thing which has a clear
> semantics.
>
>
> I agree with all conclusions of this conclusions (I knew you wouldn't need me,
> except for coding )
>
> My conclusions for RTT 2.0:
>
> * 1 activity = 1 thread by default (this is actually very logical for new users
> and in comparison to other frameworks)
Ack!
> * Serialisation is an execution model, like in 'process', 'thread', 'serialized
> thread', 'sequential'
Agreed, but whats the difference between "serialized thread" and
"sequential?
> It should be specified during deployment (ie during activity attachment to the
> component)
> * This is a FAQ item today, but could be of lesser importance once the default
> is changed
+1
Markus
single thread serialization (was flexibility vs safety)
On Thu, May 7, 2009 at 10:06 PM, Peter Soetens <peter [..] ...>wrote:
>
> My conclusions for RTT 2.0:
>
> * 1 activity = 1 thread by default (this is actually very logical for new
> users and in comparison to other frameworks)
> * Serialisation is an execution model, like in 'process', 'thread',
> 'serialized thread', 'sequential'
> It should be specified during deployment (ie during activity attachment to
> the component)
> * This is a FAQ item today, but could be of lesser importance once the
> default is changed
Forgot to add:
* Specifying a priority for saying 'run this periodic activity in the same
thread or not' is plain evil.
Also, since the order of execution depends on the order of the 'start()'s
you're in dangerous water.
We concluded before that in this case, the ordering must be made explicit by
the user, for example
by using SlaveActivity and having a periodic master execute & serialize the
slaves. This is separating the
coordination as Herman would put it...
>
>
> Peter
>
single thread serialization (was flexibility vs safety)
On Thu, May 7, 2009 at 10:06 PM, Peter Soetens <peter [..] ...>wrote:
>
> My conclusions for RTT 2.0:
>
> * 1 activity = 1 thread by default (this is actually very logical for new
> users and in comparison to other frameworks)
> * Serialisation is an execution model, like in 'process', 'thread',
> 'serialized thread', 'sequential'
> It should be specified during deployment (ie during activity attachment to
> the component)
> * This is a FAQ item today, but could be of lesser importance once the
> default is changed
Forgot to add:
* Specifying a priority for saying 'run this periodic activity in the same
thread or not' is plain evil.
Also, since the order of execution depends on the order of the 'start()'s
you're in dangerous water.
We concluded before that in this case, the ordering must be made explicit by
the user, for example
by using SlaveActivity and having a periodic master execute & serialize the
slaves. This is separating the
coordination as Herman would put it...
>
>
> Peter
>
single thread serialization (was flexibility vs safety)
________________________________
From: peter [dot] soetens [..] ... [mailto:peter [dot] soetens [..] ...] On Behalf
Of Peter Soetens
Sent: donderdag 7 mei 2009 22:23
To: Klaas Gadeyne
Cc: Vandenbroucke Sander; orocos-dev [..] ...
Subject: Re: [Orocos-Dev] single thread serialization (was flexibility
vs safety)
On Thu, May 7, 2009 at 10:06 PM, Peter Soetens
<peter [..] ...> wrote:
My conclusions for RTT 2.0:
* 1 activity = 1 thread by default (this is actually very logical for
new users and in comparison to other frameworks)
* Serialisation is an execution model, like in 'process', 'thread',
'serialized thread', 'sequential'
It should be specified during deployment (ie during activity attachment
to the component)
* This is a FAQ item today, but could be of lesser importance once the
default is changed
Forgot to add:
* Specifying a priority for saying 'run this periodic activity in the
same thread or not' is plain evil.
This is not what the priority is all about.
>From the online api documentation:
Constructor & Destructor Documentation
PeriodicActivity
<http://www.orocos.org/stable/documentation/rtt/v1.8.x/api/html/classRTT
_1_1PeriodicActivity.html>
(
int
priority,
Seconds
<http://www.orocos.org/stable/documentation/rtt/v1.8.x/api/html/namespac
eRTT.html#1f8e74f805821f3c53ea7ac83dc59092>
period,
RunnableInterface
<http://www.orocos.org/stable/documentation/rtt/v1.8.x/api/html/classRTT
_1_1OS_1_1RunnableInterface.html> *
r = 0
)
Create a Periodic Activity with a given priority and period.
The default scheduler for PeriodicActivity
<http://www.orocos.org/stable/documentation/rtt/v1.8.x/api/html/classRTT
_1_1PeriodicActivity.html> objects is ORO_SCHED_RT.
Parameters:
priority
The priority of this activity. A lookup will be done to locate a
suitable TimerThread
<http://www.orocos.org/stable/documentation/rtt/v1.8.x/api/html/classRTT
_1_1TimerThread.html> with the same priority. If it exists and it has
the same period, this activity will be executed in that thread.
Otherwise, a new TimerThread
<http://www.orocos.org/stable/documentation/rtt/v1.8.x/api/html/classRTT
_1_1TimerThread.html> is created.
period
The periodicity of the PeriodicActivity
<http://www.orocos.org/stable/documentation/rtt/v1.8.x/api/html/classRTT
_1_1PeriodicActivity.html>
r
The optional RunnableInterface
<http://www.orocos.org/stable/documentation/rtt/v1.8.x/api/html/classRTT
_1_1RunnableInterface.html> to run exclusively within this Activity
Definition at line 51
<http://www.orocos.org/stable/documentation/rtt/v1.8.x/api/html/Periodic
Activity_8cpp-source.html#l00051> of file PeriodicActivity.cpp
<http://www.orocos.org/stable/documentation/rtt/v1.8.x/api/html/Periodic
Activity_8cpp-source.html> .
As you can read: it clearly states what the priority should be. On my OS
it behaves exactly like this. I stubbornly defend my point: it is a bug
in gnulinux (without su).
Also, since the order of execution depends on the order of the
'start()'s you're in dangerous water.
Again: on my RTOS the execution depends on the priority.
We concluded before that in this case, the ordering must be made
explicit by the user, for example
by using SlaveActivity and having a periodic master execute & serialize
the slaves. This is separating the
coordination as Herman would put it...
If you are talking about the ordering of your threads: this depends on
your scheduler.
If you are talking about ordering of your activities: this depends on
the order they are added to a thread.
If you are talking about ordering of your ExecutionEngines: this depends
on the order they are added to an Activity.
If you are talking about ordering of your components: this depends on
the order they are added to an ExecutionEngine.
In short: I'm happy with how things work in RTT as it is (at least for
activities and threads).
Sander.
PS: Peter, can you try to post messages in plain text? It makes replying
easier for me :-).
Peter
______________________________________________________________________
This email has been scanned by the Email Security System.
______________________________________________________________________
single thread serialization (was flexibility vs safety)
Hi Sander,
On Fri, May 8, 2009 at 09:47, Vandenbroucke Sander
<Sander [dot] Vandenbroucke [..] ...> wrote:
> On Thu, May 7, 2009 at 10:06 PM, Peter Soetens <peter [..] ...> wrote:
>
> My conclusions for RTT 2.0:
>
> * 1 activity = 1 thread by default (this is actually very logical for new users and in comparison to other frameworks)
> * Serialisation is an execution model, like in 'process', 'thread', 'serialized thread', 'sequential'
> It should be specified during deployment (ie during activity attachment to the component)
> * This is a FAQ item today, but could be of lesser importance once the default is changed
>
> Forgot to add:
>
> * Specifying a priority for saying 'run this periodic activity in the same thread or not' is plain evil.
>
> This is not what the priority is all about.
I agree, but it is part of it ( a consequence) and users start
reasoning with 'in the same thread' quickly.
(...)
>
> As you can read: it clearly states what the priority should be. On my OS it behaves exactly like this. I stubbornly defend my point: it is a bug in gnulinux (without su).
>
> Also, since the order of execution depends on the order of the 'start()'s you're in dangerous water.
>
> Again: on my RTOS the execution depends on the priority.
I was refering to the order of execution of the activities within the
periodic thread.
>
> We concluded before that in this case, the ordering must be made explicit by the user, for example
> by using SlaveActivity and having a periodic master execute & serialize the slaves. This is separating the
> coordination as Herman would put it...
>
> If you are talking about the ordering of your threads: this depends on your scheduler.
>
> If you are talking about ordering of your activities: this depends on the order they are added to a thread.
Exactly. So in a case where you stop and start a component, the
activity is re-added to the end of the list
in that thread, and the order changed, just because of start&stop a
component, a probably common thing.
>
> If you are talking about ordering of your ExecutionEngines: this depends on the order they are added to an Activity.
>
> If you are talking about ordering of your components: this depends on the order they are added to an ExecutionEngine.
>
>
>
> In short: I’m happy with how things work in RTT as it is (at least for activities and threads).
I wasn't arguing to remove 'PeriodicActivity'. I was arguing for a
better default and let PeriodicActivity
to expert users that want this kind of serialisation of activities. In
practice, this would mean that the
default activity class will become 'RTT::Activity' (or something with
the word 'Thread' in it),
which can be both periodic and non periodic, and maps
to exactly one thread. All the other activity classes are then special cases.
>
> PS: Peter, can you try to post messages in plain text? It makes replying easier for me J.
Normally, my mail client also sends a plain text version of each
mail... I wrote this one explicitly in plain text though.
Peter
single thread serialization (was flexibility vs safety)
Hi Sander,
On Fri, May 8, 2009 at 09:47, Vandenbroucke Sander
<Sander [dot] Vandenbroucke [..] ...> wrote:
> On Thu, May 7, 2009 at 10:06 PM, Peter Soetens <peter [..] ...> wrote:
>
> My conclusions for RTT 2.0:
>
> * 1 activity = 1 thread by default (this is actually very logical for new users and in comparison to other frameworks)
> * Serialisation is an execution model, like in 'process', 'thread', 'serialized thread', 'sequential'
> It should be specified during deployment (ie during activity attachment to the component)
> * This is a FAQ item today, but could be of lesser importance once the default is changed
>
> Forgot to add:
>
> * Specifying a priority for saying 'run this periodic activity in the same thread or not' is plain evil.
>
> This is not what the priority is all about.
I agree, but it is part of it ( a consequence) and users start
reasoning with 'in the same thread' quickly.
(...)
>
> As you can read: it clearly states what the priority should be. On my OS it behaves exactly like this. I stubbornly defend my point: it is a bug in gnulinux (without su).
>
> Also, since the order of execution depends on the order of the 'start()'s you're in dangerous water.
>
> Again: on my RTOS the execution depends on the priority.
I was refering to the order of execution of the activities within the
periodic thread.
>
> We concluded before that in this case, the ordering must be made explicit by the user, for example
> by using SlaveActivity and having a periodic master execute & serialize the slaves. This is separating the
> coordination as Herman would put it...
>
> If you are talking about the ordering of your threads: this depends on your scheduler.
>
> If you are talking about ordering of your activities: this depends on the order they are added to a thread.
Exactly. So in a case where you stop and start a component, the
activity is re-added to the end of the list
in that thread, and the order changed, just because of start&stop a
component, a probably common thing.
>
> If you are talking about ordering of your ExecutionEngines: this depends on the order they are added to an Activity.
>
> If you are talking about ordering of your components: this depends on the order they are added to an ExecutionEngine.
>
>
>
> In short: I’m happy with how things work in RTT as it is (at least for activities and threads).
I wasn't arguing to remove 'PeriodicActivity'. I was arguing for a
better default and let PeriodicActivity
to expert users that want this kind of serialisation of activities. In
practice, this would mean that the
default activity class will become 'RTT::Activity' (or something with
the word 'Thread' in it),
which can be both periodic and non periodic, and maps
to exactly one thread. All the other activity classes are then special cases.
>
> PS: Peter, can you try to post messages in plain text? It makes replying easier for me J.
Normally, my mail client also sends a plain text version of each
mail... I wrote this one explicitly in plain text though.
Peter
single thread serialization (was flexibility vs safety)
Peter,
> > * Specifying a priority for saying 'run this periodic activity in
the
> same thread or not' is plain evil.
> >
> > This is not what the priority is all about.
>
> I agree, but it is part of it ( a consequence) and users start
> reasoning with 'in the same thread' quickly.
>
So we agree on either:
- There a short coming in the documentation about the role of the
priority.
- There is a bug in the current TimerThread implementation in gnulinux
(what this thread started).
> >
> > We concluded before that in this case, the ordering must be made
> explicit by the user, for example
> > by using SlaveActivity and having a periodic master execute &
serialize
> the slaves. This is separating the
> > coordination as Herman would put it...
> >
> > If you are talking about the ordering of your threads: this depends
on
> your scheduler.
> >
> > If you are talking about ordering of your activities: this depends
on
> the order they are added to a thread.
>
> Exactly. So in a case where you stop and start a component, the
> activity is re-added to the end of the list
> in that thread, and the order changed, just because of start&stop a
> component, a probably common thing.
>
Ok, I just got the point you made before with the SlaveActivity.
> > In short: I'm happy with how things work in RTT as it is (at least
for
> activities and threads).
>
> I wasn't arguing to remove 'PeriodicActivity'. I was arguing for a
> better default and let PeriodicActivity
> to expert users that want this kind of serialisation of activities. In
> practice, this would mean that the
> default activity class will become 'RTT::Activity' (or something with
> the word 'Thread' in it),
> which can be both periodic and non periodic, and maps
> to exactly one thread. All the other activity classes are then special
> cases.
>
Ok, I think Activity is just fine. Isn't Thread already too narrow?
>
> >
> > PS: Peter, can you try to post messages in plain text? It makes
replying
> easier for me J.
>
> Normally, my mail client also sends a plain text version of each
> mail... I wrote this one explicitly in plain text though.
>
Before I received them as HTML, this one is fine!
Sander.
single thread serialization (was flexibility vs safety)
On Thursday 07 May 2009 22:22:53 Peter Soetens wrote:
> On Thu, May 7, 2009 at 10:06 PM, Peter Soetens
<peter [..] ...>wrote:
> > My conclusions for RTT 2.0:
> >
> > * 1 activity = 1 thread by default (this is actually very logical for new
> > users and in comparison to other frameworks)
> > * Serialisation is an execution model, like in 'process', 'thread',
> > 'serialized thread', 'sequential'
> > It should be specified during deployment (ie during activity attachment
> > to the component)
> > * This is a FAQ item today, but could be of lesser importance once the
> > default is changed
+1
> Forgot to add:
>
> * Specifying a priority for saying 'run this periodic activity in the same
> thread or not' is plain evil.
> Also, since the order of execution depends on the order of the 'start()'s
> you're in dangerous water.
> We concluded before that in this case, the ordering must be made explicit
> by the user, for example
> by using SlaveActivity and having a periodic master execute & serialize the
> slaves. This is separating the
> coordination as Herman would put it...
And +1.
Sylvain
single thread serialization (was flexibility vs safety)
On Thu, 7 May 2009, Peter Soetens wrote:
> Thanks to Davide for raising this issue:
>
> On Mon, May 4, 2009 at 11:50 AM, Klaas Gadeyne <klaas [dot] gadeyne [..] ...>
> wrote:
> On Mon, 4 May 2009, Vandenbroucke Sander wrote:
> > So basically nothing is wrong with RTT (except for
> documentation) on
> > this issue, it is just how the user uses it that is wrong.
>
> Well (to repeat myself), I still think the "thread serialization"
> feature should become optional.
>
> As a side note: I think this example has been _very_ useful to be able
> to discuss about RTT without falling into what I would call
> "high-level false-true" discussions (thank you Davide). And I think
> it's a good way to discuss RTT 2.0 issues on this level, because
> (given the lack of using diagrams :-) currently the code is the only
> thing which has a clear semantics.
>
>
> I agree with all conclusions of this conclusions (I knew you wouldn't need
> me, except for coding )
>
> My conclusions for RTT 2.0:
>
> * 1 activity = 1 thread by default (this is actually very logical for new
> users and in comparison to other frameworks)
> * Serialisation is an execution model, like in 'process', 'thread',
> 'serialized thread', 'sequential'
> It should be specified during deployment (ie during activity attachment to
> the component)
Agreed!
Herman
> * This is a FAQ item today, but could be of lesser importance once the
> default is changed
>
> Peter
>
>
--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 322480
Coordinator of EURON (European Robotics Research Network)
<http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>