Hi,
when running an orocos application on 1.10 (svn branch) in xenomai (2.4 branch), a (NonPeriodic)Activity (hence thread) is created by default. However, it seems like there is a serious waste of resources going on, unless I'm missing something...
Look at the output of following application:
proc/xenomai$ cat sched
CPU PID PRI PERIOD TIMEOUT TIMEBASE STAT NAME
0 0 -1 0 0 master R ROOT
0 12288 10 0 0 master X MainThread
0 12289 1 0 0 master W Deployer
0 12290 1 0 0 master W CANAdaptor
0 12291 99 0 42539962 master w NonPeriodicActivity
0 12292 99 20000000 7206019 master D TimerThreadInstance
0 12293 1 0 0 master W IOMapping
0 12295 10 1000000 431221 master D TimerThreadInstance1
0 12296 1 0 0 master W S1
0 12299 1 2000000 1646261 master D TimerThreadInstance2
0 12300 1 0 0 master W S2
0 12301 1 0 0 master W S3
0 12302 1 0 0 master W S4
0 12303 1 0 0 master W S4
0 12304 1 0 0 master W Reporting
0 12308 1 100000000 76760718 master D TimerThreadInstance3
0 12309 1 0 0 master W Blabla1
0 12311 99 0 0 master W NonPeriodicActivity1
0 12312 1 0 0 master W Blabla2
0 12317 15 5000000 551002 master D TimerThreadInstance4
0 12318 1 0 0 master W Blabla3
0 12321 99 0 0 master W NonPeriodicActivity2
0 12322 1 0 0 master W Blabla4
0 12328 1 1000000 192684 master D TimerThreadInstance5
0 12329 1 0 0 master W Blabla5
0 12336 1 100000000 90365895 master D TimerThreadInstance6
0 12337 1 0 0 master W TaskBrowser
For instance, the component IOmapping is configured in the deployers file as being connected to a periodic activity of priority 10 and period of 1 ms. In the output from /proc/xenomai/sched, I have the impression that first a nonPeriodicthread is created (the "default" activity) with name IOmapping (PID 12293), and then, when configuring the component, a Periodic thread is created to do the actual work with a meaningless name (TimerThreadInstance1, PID 12292). Moreover, the original thread cleaned up however :-(
The "Sx" components are all Simulink components running at the same frequency. Although the actual code seems to be running in a single thread (TimerThreadInstance2), 5 NonPeriodicThreads are created.
Did we do something wrong or is this intended behaviour? And if the answer is: "the latter": are we then not wasting resources here and complicate the debugging process (the benefit of naming the thread after its component has completely disappeared it seems)?
Best regards,
Klaas
New 1.10 activity model creates useless threads?
On Thu, Nov 26, 2009 at 13:43, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
> Hi,
>
> when running an orocos application on 1.10 (svn branch) in xenomai (2.4 branch), a (NonPeriodic)Activity (hence thread) is created by default. However, it seems like there is a serious waste of resources going on, unless I'm missing something...
>
> Look at the output of following application:
>
> proc/xenomai$ cat sched
>
> CPU PID PRI PERIOD TIMEOUT TIMEBASE STAT NAME
> 0 0 -1 0 0 master R ROOT
> 0 12288 10 0 0 master X MainThread
> 0 12289 1 0 0 master W Deployer
> 0 12290 1 0 0 master W CANAdaptor
> 0 12291 99 0 42539962 master w NonPeriodicActivity
> 0 12292 99 20000000 7206019 master D TimerThreadInstance
> 0 12293 1 0 0 master W IOMapping
> 0 12295 10 1000000 431221 master D TimerThreadInstance1
> 0 12296 1 0 0 master W S1
> 0 12299 1 2000000 1646261 master D TimerThreadInstance2
> 0 12300 1 0 0 master W S2
> 0 12301 1 0 0 master W S3
> 0 12302 1 0 0 master W S4
> 0 12303 1 0 0 master W S4
> 0 12304 1 0 0 master W Reporting
> 0 12308 1 100000000 76760718 master D TimerThreadInstance3
> 0 12309 1 0 0 master W Blabla1
> 0 12311 99 0 0 master W NonPeriodicActivity1
> 0 12312 1 0 0 master W Blabla2
> 0 12317 15 5000000 551002 master D TimerThreadInstance4
> 0 12318 1 0 0 master W Blabla3
> 0 12321 99 0 0 master W NonPeriodicActivity2
> 0 12322 1 0 0 master W Blabla4
> 0 12328 1 1000000 192684 master D TimerThreadInstance5
> 0 12329 1 0 0 master W Blabla5
> 0 12336 1 100000000 90365895 master D TimerThreadInstance6
> 0 12337 1 0 0 master W TaskBrowser
>
> For instance, the component IOmapping is configured in the deployers file as being connected to a periodic activity of priority 10 and period of 1 ms. In the output from /proc/xenomai/sched, I have the impression that first a nonPeriodicthread is created (the "default" activity) with name IOmapping (PID 12293), and then, when configuring the component, a Periodic thread is created to do the actual work with a meaningless name (TimerThreadInstance1, PID 12292). Moreover, the original thread cleaned up however :-(
You need to specify 'Activity' instead of 'PeriodicActivity' in your
deployer file. The behaviour is that if you specify an activity in
your deployment xml file, the current one is cleaned up and the new
one is installed. Unfortunately, the deployer does not yet assign the
component's name to the 'Activity', which is a one-liner to fix.
> The "Sx" components are all Simulink components running at the same frequency. Although the actual code seems to be running in a single thread (TimerThreadInstance2), 5 NonPeriodicThreads are created.
They should have been cleaned up.
>
> Did we do something wrong or is this intended behaviour? And if the answer is: "the latter": are we then not wasting resources here and complicate the debugging process (the benefit of naming the thread after its component has completely disappeared it seems)?
It's an issue we need to fix in the deployer.
So I see two issues here:
* Old thread is not cleaned up when new one is assigned.
* TC Name is not passed during activity creation when using deployer.
Correct ?
Peter
New 1.10 activity model creates useless threads?
On Thu, Nov 26, 2009 at 2:05 PM, Peter Soetens <peter [..] ...> wrote:
> On Thu, Nov 26, 2009 at 13:43, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>> Hi,
>>
>> when running an orocos application on 1.10 (svn branch) in xenomai (2.4 branch), a (NonPeriodic)Activity (hence thread) is created by default. However, it seems like there is a serious waste of resources going on, unless I'm missing something...
>>
>> Look at the output of following application:
>>
>> proc/xenomai$ cat sched
>>
>> CPU PID PRI PERIOD TIMEOUT TIMEBASE STAT NAME
>> 0 0 -1 0 0 master R ROOT
>> 0 12288 10 0 0 master X MainThread
>> 0 12289 1 0 0 master W Deployer
>> 0 12290 1 0 0 master W CANAdaptor
>> 0 12291 99 0 42539962 master w NonPeriodicActivity
>> 0 12292 99 20000000 7206019 master D TimerThreadInstance
>> 0 12293 1 0 0 master W IOMapping
>> 0 12295 10 1000000 431221 master D TimerThreadInstance1
>> 0 12296 1 0 0 master W S1
>> 0 12299 1 2000000 1646261 master D TimerThreadInstance2
>> 0 12300 1 0 0 master W S2
>> 0 12301 1 0 0 master W S3
>> 0 12302 1 0 0 master W S4
>> 0 12303 1 0 0 master W S4
>> 0 12304 1 0 0 master W Reporting
>> 0 12308 1 100000000 76760718 master D TimerThreadInstance3
>> 0 12309 1 0 0 master W Blabla1
>> 0 12311 99 0 0 master W NonPeriodicActivity1
>> 0 12312 1 0 0 master W Blabla2
>> 0 12317 15 5000000 551002 master D TimerThreadInstance4
>> 0 12318 1 0 0 master W Blabla3
>> 0 12321 99 0 0 master W NonPeriodicActivity2
>> 0 12322 1 0 0 master W Blabla4
>> 0 12328 1 1000000 192684 master D TimerThreadInstance5
>> 0 12329 1 0 0 master W Blabla5
>> 0 12336 1 100000000 90365895 master D TimerThreadInstance6
>> 0 12337 1 0 0 master W TaskBrowser
>>
>> For instance, the component IOmapping is configured in the deployers file as being connected to a periodic activity of priority 10 and period of 1 ms. In the output from /proc/xenomai/sched, I have the impression that first a nonPeriodicthread is created (the "default" activity) with name IOmapping (PID 12293), and then, when configuring the component, a Periodic thread is created to do the actual work with a meaningless name (TimerThreadInstance1, PID 12292). Moreover, the original thread cleaned up however :-(
>
> You need to specify 'Activity' instead of 'PeriodicActivity' in your
> deployer file. The behaviour is that if you specify an activity in
> your deployment xml file, the current one is cleaned up and the new
> one is installed. Unfortunately, the deployer does not yet assign the
> component's name to the 'Activity', which is a one-liner to fix.
emuldebug@apollo:~/SVN/ocl-1.10$ svn diff deployment/DeploymentComponent.cpp
Index: deployment/DeploymentComponent.cpp
===================================================================
--- deployment/DeploymentComponent.cpp (revision 31071)
+++ deployment/DeploymentComponent.cpp (working copy)
@@ -1778,7 +1778,7 @@
}
else
if (act_type == "Activity") {
- newact = new Activity(scheduler, priority, period);
+ newact = new Activity(scheduler, priority,
period, 0, comp_name);
}
else
if (act_type == "SequentialActivity") {
Klaas
New 1.10 activity model creates useless threads?
On Thu, Nov 26, 2009 at 18:35, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
> On Thu, Nov 26, 2009 at 2:05 PM, Peter Soetens <peter [..] ...> wrote:
>> On Thu, Nov 26, 2009 at 13:43, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>>> Hi,
>>>
>>> when running an orocos application on 1.10 (svn branch) in xenomai (2.4 branch), a (NonPeriodic)Activity (hence thread) is created by default. However, it seems like there is a serious waste of resources going on, unless I'm missing something...
>>>
>>> Look at the output of following application:
>>>
>>> proc/xenomai$ cat sched
>>>
>>> CPU PID PRI PERIOD TIMEOUT TIMEBASE STAT NAME
>>> 0 0 -1 0 0 master R ROOT
>>> 0 12288 10 0 0 master X MainThread
>>> 0 12289 1 0 0 master W Deployer
>>> 0 12290 1 0 0 master W CANAdaptor
>>> 0 12291 99 0 42539962 master w NonPeriodicActivity
>>> 0 12292 99 20000000 7206019 master D TimerThreadInstance
>>> 0 12293 1 0 0 master W IOMapping
>>> 0 12295 10 1000000 431221 master D TimerThreadInstance1
>>> 0 12296 1 0 0 master W S1
>>> 0 12299 1 2000000 1646261 master D TimerThreadInstance2
>>> 0 12300 1 0 0 master W S2
>>> 0 12301 1 0 0 master W S3
>>> 0 12302 1 0 0 master W S4
>>> 0 12303 1 0 0 master W S4
>>> 0 12304 1 0 0 master W Reporting
>>> 0 12308 1 100000000 76760718 master D TimerThreadInstance3
>>> 0 12309 1 0 0 master W Blabla1
>>> 0 12311 99 0 0 master W NonPeriodicActivity1
>>> 0 12312 1 0 0 master W Blabla2
>>> 0 12317 15 5000000 551002 master D TimerThreadInstance4
>>> 0 12318 1 0 0 master W Blabla3
>>> 0 12321 99 0 0 master W NonPeriodicActivity2
>>> 0 12322 1 0 0 master W Blabla4
>>> 0 12328 1 1000000 192684 master D TimerThreadInstance5
>>> 0 12329 1 0 0 master W Blabla5
>>> 0 12336 1 100000000 90365895 master D TimerThreadInstance6
>>> 0 12337 1 0 0 master W TaskBrowser
>>>
>>> For instance, the component IOmapping is configured in the deployers file as being connected to a periodic activity of priority 10 and period of 1 ms. In the output from /proc/xenomai/sched, I have the impression that first a nonPeriodicthread is created (the "default" activity) with name IOmapping (PID 12293), and then, when configuring the component, a Periodic thread is created to do the actual work with a meaningless name (TimerThreadInstance1, PID 12292). Moreover, the original thread cleaned up however :-(
>>
>> You need to specify 'Activity' instead of 'PeriodicActivity' in your
>> deployer file. The behaviour is that if you specify an activity in
>> your deployment xml file, the current one is cleaned up and the new
>> one is installed. Unfortunately, the deployer does not yet assign the
>> component's name to the 'Activity', which is a one-liner to fix.
>
> emuldebug@apollo:~/SVN/ocl-1.10$ svn diff deployment/DeploymentComponent.cpp
> Index: deployment/DeploymentComponent.cpp
> ===================================================================
> --- deployment/DeploymentComponent.cpp (revision 31071)
> +++ deployment/DeploymentComponent.cpp (working copy)
> @@ -1778,7 +1778,7 @@
> }
> else
> if (act_type == "Activity") {
> - newact = new Activity(scheduler, priority, period);
> + newact = new Activity(scheduler, priority,
> period, 0, comp_name);
> }
> else
> if (act_type == "SequentialActivity") {
The correct patch is in attachment. It's on ocl trunk and 1.10 branch
too. It fixes both issues, but I'm eager to learn what it gives in
your setup.
Peter
New 1.10 activity model creates useless threads?
On Thu, Nov 26, 2009 at 11:15 PM, Peter Soetens
<peter [..] ...> wrote:
[...]
> The correct patch is in attachment. It's on ocl trunk and 1.10 branch
> too. It fixes both issues, but I'm eager to learn what it gives in
> your setup.
In my setup it works only partly: The activities now have both a their
components name (well, suffixed by a 1 since its the second activity
registered with that name) and the useless original threads are
removed. However, there seems to be 2 unwanted side effects:
1/ Activities with the same priority/period are no longer grouped into
the same thread. Unless that's an undocumented feature of this patch?
2/ For the reporting component, the patch somehow seems to lead to an
infinite recursion. (part of) backtrace attached.
Klaas
ps1. As at least the issue of having double threads seems to be
major, maybe we should continue in bugzilla?
ps2. The default activity of a component also has another nasty side
effect: It generates unnecessary warnings When starting up my
application, I get
$ deployer-xenomai -s myapp-xenomai.cpf
0.006 [ Warning][Thread] Forcing priority (0) of thread to 1.
0.986 [ Warning][Thread] Forcing priority (0) of thread to 1.
0.992 [ Warning][Thread] Forcing priority (0) of thread to 1.
0.999 [ Warning][Thread] Forcing priority (0) of thread to 1.
1.004 [ Warning][Thread] Forcing priority (0) of thread to 1.
1.012 [ Warning][Thread] Forcing priority (0) of thread to 1.
1.022 [ Warning][Thread] Forcing priority (0) of thread to 1.
1.029 [ Warning][Thread] Forcing priority (0) of thread to 1.
1.035 [ Warning][Thread] Forcing priority (0) of thread to 1.
1.038 [ Warning][Thread] Forcing priority (0) of thread to 1.
1.041 [ Warning][Thread] Forcing priority (0) of thread to 1.
1.046 [ Warning][Thread] Forcing priority (0) of thread to 1.
1.047 [ Warning][Thread] Forcing priority (0) of thread to 1.
1.049 [ Warning][Thread] Forcing priority (0) of thread to 1.
1.053 [ Warning][Thread] Forcing priority (0) of thread to 1.
We didn't previously understand where these were coming from, since
all our thread priorities were correct. Of course now I understand
these warnings are coming from the default activities that are removed
later on and not used (or desired/specified) by my application.
New 1.10 activity model creates useless threads?
On Fri, Nov 27, 2009 at 18:07, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
> On Thu, Nov 26, 2009 at 11:15 PM, Peter Soetens
> <peter [..] ...> wrote:
>
> [...]
>> The correct patch is in attachment. It's on ocl trunk and 1.10 branch
>> too. It fixes both issues, but I'm eager to learn what it gives in
>> your setup.
>
> In my setup it works only partly: The activities now have both a their
> components name (well, suffixed by a 1 since its the second activity
> registered with that name) and the useless original threads are
> removed. However, there seems to be 2 unwanted side effects:
>
> 1/ Activities with the same priority/period are no longer grouped into
> the same thread. Unless that's an undocumented feature of this patch?
RTT::PeriodicActivity still exists if you want that. Plain
RTT::Activity is a 'one thread per component' model. It is still
recommended to use SlaveActivity with a periodic master in case you
want to serialize components in one thread. PeriodicActivity does not
allow the same level of control of ordering the executions.
> 2/ For the reporting component, the patch somehow seems to lead to an
> infinite recursion. (part of) backtrace attached.
This was already fixed, but not yet ported back to the 1.10 branch.
I'll port it asap.
>
> Klaas
>
> ps1. As at least the issue of having double threads seems to be
> major, maybe we should continue in bugzilla?
It's also a bit late now, but I won't stop you.
> ps2. The default activity of a component also has another nasty side
> effect: It generates unnecessary warnings When starting up my
> application, I get
>
> $ deployer-xenomai -s myapp-xenomai.cpf
> 0.006 [ Warning][Thread] Forcing priority (0) of thread to 1.
That needs to be fixed.
Peter
New 1.10 activity model creates useless threads?
On Mon, Nov 30, 2009 at 10:14 AM, Peter Soetens
<peter [..] ...> wrote:
> On Fri, Nov 27, 2009 at 18:07, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>> On Thu, Nov 26, 2009 at 11:15 PM, Peter Soetens
>> <peter [..] ...> wrote:
>>
>> [...]
>>> The correct patch is in attachment. It's on ocl trunk and 1.10 branch
>>> too. It fixes both issues, but I'm eager to learn what it gives in
>>> your setup.
>>
>> In my setup it works only partly: The activities now have both a their
>> components name (well, suffixed by a 1 since its the second activity
>> registered with that name) and the useless original threads are
>> removed. However, there seems to be 2 unwanted side effects:
>>
>> 1/ Activities with the same priority/period are no longer grouped into
>> the same thread. Unless that's an undocumented feature of this patch?
>
> RTT::PeriodicActivity still exists if you want that. Plain
> RTT::Activity is a 'one thread per component' model. It is still
> recommended to use SlaveActivity with a periodic master in case you
> want to serialize components in one thread. PeriodicActivity does not
> allow the same level of control of ordering the executions.
Hmm, is the following correct for 1.10 (xenomai at least, didn't check
for other OSes, but I guess it might hold too): If I specify the
activity type in the deployers file as
- Activity
* I get One "named" thread per component, and Activities are no
longer grouped into threads
- PeriodicActivity
* I end up with with 2 "unnamed" threads per component, but
Activities are grouped into threads.
I haven't tested SlaveActivity with Simulink components yet, but it's
too close to a deadline and I somehow have a feeling that it won't
work out-of-the-box :-)
>> 2/ For the reporting component, the patch somehow seems to lead to an
>> infinite recursion. (part of) backtrace attached.
>
> This was already fixed, but not yet ported back to the 1.10 branch.
> I'll port it asap.
I hate "silent" fixes :-(
Thx for porting!
Klaas
New 1.10 activity model creates useless threads?
On Mon, Nov 30, 2009 at 11:14, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
> On Mon, Nov 30, 2009 at 10:14 AM, Peter Soetens
> <peter [..] ...> wrote:
>> On Fri, Nov 27, 2009 at 18:07, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>>> On Thu, Nov 26, 2009 at 11:15 PM, Peter Soetens
>>> <peter [..] ...> wrote:
>>>
>>> [...]
>>>> The correct patch is in attachment. It's on ocl trunk and 1.10 branch
>>>> too. It fixes both issues, but I'm eager to learn what it gives in
>>>> your setup.
>>>
>>> In my setup it works only partly: The activities now have both a their
>>> components name (well, suffixed by a 1 since its the second activity
>>> registered with that name) and the useless original threads are
>>> removed. However, there seems to be 2 unwanted side effects:
>>>
>>> 1/ Activities with the same priority/period are no longer grouped into
>>> the same thread. Unless that's an undocumented feature of this patch?
>>
>> RTT::PeriodicActivity still exists if you want that. Plain
>> RTT::Activity is a 'one thread per component' model. It is still
>> recommended to use SlaveActivity with a periodic master in case you
>> want to serialize components in one thread. PeriodicActivity does not
>> allow the same level of control of ordering the executions.
>
> Hmm, is the following correct for 1.10 (xenomai at least, didn't check
> for other OSes, but I guess it might hold too): If I specify the
> activity type in the deployers file as
> - Activity
> * I get One "named" thread per component, and Activities are no
> longer grouped into threads
Correct.
> - PeriodicActivity
> * I end up with with 2 "unnamed" threads per component, but
> Activities are grouped into threads.
Wrong. You're mixing the bug with the new behaviour. The goal is this:
a 1.6,1.8,1.10,... application should have exactly the same number of
threads independent of the version. Any deviation is a bug. 'Activity'
was created as an add-on, not a replacement. The notable exception
here is that in 1.8, the default activity was SequentialActivity,
which was considered to be bad, so we changed that default to
'Activity'. In this sense, 1.10 applications have more threads if you
leave components in the default configured state. If you would
configure every component, all defaults would be replaced by your
pickings.
- PeriodicActivity
* I end up with one thread 'TimerThreadX' for each (scheduler,priority) group
created by PeriodicActivity users. Just like it used to be.
>
> I haven't tested SlaveActivity with Simulink components yet, but it's
> too close to a deadline and I somehow have a feeling that it won't
> work out-of-the-box :-)
We need tooling to make this a 'checkbox-change' test...
Peter
New 1.10 activity model creates useless threads?
On Mon, 30 Nov 2009, Peter Soetens wrote:
> On Mon, Nov 30, 2009 at 11:14, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>> On Mon, Nov 30, 2009 at 10:14 AM, Peter Soetens
>> <peter [..] ...> wrote:
>>> On Fri, Nov 27, 2009 at 18:07, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>>>> On Thu, Nov 26, 2009 at 11:15 PM, Peter Soetens
>>>> <peter [..] ...> wrote:
>>>>
>>>> [...]
>>>>> The correct patch is in attachment. It's on ocl trunk and 1.10 branch
>>>>> too. It fixes both issues, but I'm eager to learn what it gives in
>>>>> your setup.
>>>>
>>>> In my setup it works only partly: The activities now have both a their
>>>> components name (well, suffixed by a 1 since its the second activity
>>>> registered with that name) and the useless original threads are
>>>> removed. However, there seems to be 2 unwanted side effects:
>>>>
>>>> 1/ Activities with the same priority/period are no longer grouped into
>>>> the same thread. Unless that's an undocumented feature of this patch?
>>>
>>> RTT::PeriodicActivity still exists if you want that. Plain
>>> RTT::Activity is a 'one thread per component' model. It is still
>>> recommended to use SlaveActivity with a periodic master in case you
>>> want to serialize components in one thread. PeriodicActivity does not
>>> allow the same level of control of ordering the executions.
>>
>> Hmm, is the following correct for 1.10 (xenomai at least, didn't check
>> for other OSes, but I guess it might hold too): If I specify the
>> activity type in the deployers file as
>> - Activity
>> * I get One "named" thread per component, and Activities are no
>> longer grouped into threads
>
> Correct.
>
>> - PeriodicActivity
>> * I end up with with 2 "unnamed" threads per component, but
>> Activities are grouped into threads.
>
> Wrong. You're mixing the bug with the new behaviour. The goal is this:
> a 1.6,1.8,1.10,... application should have exactly the same number of
> threads independent of the version. Any deviation is a bug. 'Activity'
> was created as an add-on, not a replacement. The notable exception
> here is that in 1.8, the default activity was SequentialActivity,
> which was considered to be bad, so we changed that default to
> 'Activity'. In this sense, 1.10 applications have more threads if you
> leave components in the default configured state. If you would
> configure every component, all defaults would be replaced by your
> pickings.
>
> - PeriodicActivity
> * I end up with one thread 'TimerThreadX' for each (scheduler,priority) group
> created by PeriodicActivity users. Just like it used to be.
ACK. I somehow must have been confused by your original suggestion of switching periodicActivity to activity and have messed up when testing. I now also "got rid of" the 2 threads per component when using Periodic.
Thx!
k
New 1.10 activity model creates useless threads?
On Mon, Nov 30, 2009 at 10:14, Peter Soetens <peter [..] ...> wrote:
> On Fri, Nov 27, 2009 at 18:07, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>> On Thu, Nov 26, 2009 at 11:15 PM, Peter Soetens
>> <peter [..] ...> wrote:
>>
>> [...]
>>> The correct patch is in attachment. It's on ocl trunk and 1.10 branch
>>> too. It fixes both issues, but I'm eager to learn what it gives in
>>> your setup.
>>
>> In my setup it works only partly: The activities now have both a their
>> components name (well, suffixed by a 1 since its the second activity
>> registered with that name) and the useless original threads are
>> removed. However, there seems to be 2 unwanted side effects:
>>
>> 1/ Activities with the same priority/period are no longer grouped into
>> the same thread. Unless that's an undocumented feature of this patch?
>
> RTT::PeriodicActivity still exists if you want that. Plain
> RTT::Activity is a 'one thread per component' model. It is still
> recommended to use SlaveActivity with a periodic master in case you
> want to serialize components in one thread. PeriodicActivity does not
> allow the same level of control of ordering the executions.
>
>> 2/ For the reporting component, the patch somehow seems to lead to an
>> infinite recursion. (part of) backtrace attached.
>
> This was already fixed, but not yet ported back to the 1.10 branch.
> I'll port it asap.
>
>>
>> Klaas
>>
>> ps1. As at least the issue of having double threads seems to be
>> major, maybe we should continue in bugzilla?
>
> It's also a bit late now, but I won't stop you.
>
>> ps2. The default activity of a component also has another nasty side
>> effect: It generates unnecessary warnings When starting up my
>> application, I get
>>
>> $ deployer-xenomai -s myapp-xenomai.cpf
>> 0.006 [ Warning][Thread] Forcing priority (0) of thread to 1.
>
> That needs to be fixed.
This is actually related to the 'bogus Xenomai scheduler settings' bug
I submitted last week. Would it suit you to test the fix for this bug
this week ?
https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=739
We could rename the activity created by default by the TC to
TC.getName() + "DefActivity" ? Such that the deployer is allowed to
use TC.getName() to create the new activity ?
Peter
New 1.10 activity model creates useless threads?
On Mon, Nov 30, 2009 at 11:00 AM, Peter Soetens
<peter [..] ...> wrote:
> On Mon, Nov 30, 2009 at 10:14, Peter Soetens <peter [..] ...> wrote:
>> On Fri, Nov 27, 2009 at 18:07, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>>> On Thu, Nov 26, 2009 at 11:15 PM, Peter Soetens
>>> <peter [..] ...> wrote:
>>>
>>> [...]
>>>> The correct patch is in attachment. It's on ocl trunk and 1.10 branch
>>>> too. It fixes both issues, but I'm eager to learn what it gives in
>>>> your setup.
>>>
>>> In my setup it works only partly: The activities now have both a their
>>> components name (well, suffixed by a 1 since its the second activity
>>> registered with that name) and the useless original threads are
>>> removed. However, there seems to be 2 unwanted side effects:
>>>
>>> 1/ Activities with the same priority/period are no longer grouped into
>>> the same thread. Unless that's an undocumented feature of this patch?
>>
>> RTT::PeriodicActivity still exists if you want that. Plain
>> RTT::Activity is a 'one thread per component' model. It is still
>> recommended to use SlaveActivity with a periodic master in case you
>> want to serialize components in one thread. PeriodicActivity does not
>> allow the same level of control of ordering the executions.
>>
>>> 2/ For the reporting component, the patch somehow seems to lead to an
>>> infinite recursion. (part of) backtrace attached.
>>
>> This was already fixed, but not yet ported back to the 1.10 branch.
>> I'll port it asap.
>>
>>>
>>> Klaas
>>>
>>> ps1. As at least the issue of having double threads seems to be
>>> major, maybe we should continue in bugzilla?
>>
>> It's also a bit late now, but I won't stop you.
>>
>>> ps2. The default activity of a component also has another nasty side
>>> effect: It generates unnecessary warnings When starting up my
>>> application, I get
>>>
>>> $ deployer-xenomai -s myapp-xenomai.cpf
>>> 0.006 [ Warning][Thread] Forcing priority (0) of thread to 1.
>>
>> That needs to be fixed.
>
> This is actually related to the 'bogus Xenomai scheduler settings' bug
> I submitted last week. Would it suit you to test the fix for this bug
> this week ?
> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=739
I'll try, but I'm not sure I'll have some time. The sooner I get a
patch, the more chances I'll be able to test this week.
> We could rename the activity created by default by the TC to
> TC.getName() + "DefActivity" ? Such that the deployer is allowed to
> use TC.getName() to create the new activity ?
Sound ok, although I don't really mind the "1" suffix as it doesn't
really hinder debugging.
Klaas
New 1.10 activity model creates useless threads?
On Fri, Nov 27, 2009 at 6:07 PM, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
[...]
> 2/ For the reporting component, the patch somehow seems to lead to an
> infinite recursion. (part of) backtrace attached.
A closer look at the backtrace leads me to think this is an RTT bug in
Activity.cpp (recursively calling of start), but I'm not sure what's
the best way to fix it. It seems to be a different bug, which is just
triggered by switching from PeriodicActivity to Activity in the
deployers file and has nothing to do with the deployer itself.
It can be "avoided" by not connecting the reportingComponent to an
Activity but to a PeriodicActivity.
Klaas
New 1.10 activity model creates useless threads?
On Thu, 26 Nov 2009, Peter Soetens wrote:
> On Thu, Nov 26, 2009 at 13:43, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>> Hi,
>>
>> when running an orocos application on 1.10 (svn branch) in xenomai (2.4 branch), a (NonPeriodic)Activity (hence thread) is created by default. However, it seems like there is a serious waste of resources going on, unless I'm missing something...
>>
>> Look at the output of following application:
>>
>> proc/xenomai$ cat sched
>>
>> CPU PID PRI PERIOD TIMEOUT TIMEBASE STAT NAME
>> 0 0 -1 0 0 master R ROOT
>> 0 12288 10 0 0 master X MainThread
>> 0 12289 1 0 0 master W Deployer
>> 0 12290 1 0 0 master W CANAdaptor
>> 0 12291 99 0 42539962 master w NonPeriodicActivity
>> 0 12292 99 20000000 7206019 master D TimerThreadInstance
>> 0 12293 1 0 0 master W IOMapping
>> 0 12295 10 1000000 431221 master D TimerThreadInstance1
>> 0 12296 1 0 0 master W S1
>> 0 12299 1 2000000 1646261 master D TimerThreadInstance2
>> 0 12300 1 0 0 master W S2
>> 0 12301 1 0 0 master W S3
>> 0 12302 1 0 0 master W S4
>> 0 12303 1 0 0 master W S4
>> 0 12304 1 0 0 master W Reporting
>> 0 12308 1 100000000 76760718 master D TimerThreadInstance3
>> 0 12309 1 0 0 master W Blabla1
>> 0 12311 99 0 0 master W NonPeriodicActivity1
>> 0 12312 1 0 0 master W Blabla2
>> 0 12317 15 5000000 551002 master D TimerThreadInstance4
>> 0 12318 1 0 0 master W Blabla3
>> 0 12321 99 0 0 master W NonPeriodicActivity2
>> 0 12322 1 0 0 master W Blabla4
>> 0 12328 1 1000000 192684 master D TimerThreadInstance5
>> 0 12329 1 0 0 master W Blabla5
>> 0 12336 1 100000000 90365895 master D TimerThreadInstance6
>> 0 12337 1 0 0 master W TaskBrowser
>>
>> For instance, the component IOmapping is configured in the deployers file as being connected to a periodic activity of priority 10 and period of 1 ms. In the output from /proc/xenomai/sched, I have the impression that first a nonPeriodicthread is created (the "default" activity) with name IOmapping (PID 12293), and then, when configuring the component, a Periodic thread is created to do the actual work with a meaningless name (TimerThreadInstance1, PID 12292). Moreover, the original thread cleaned up however :-(
>
> You need to specify 'Activity' instead of 'PeriodicActivity' in your
> deployer file. The behaviour is that if you specify an activity in
> your deployment xml file, the current one is cleaned up and the new
> one is installed. Unfortunately, the deployer does not yet assign the
> component's name to the 'Activity', which is a one-liner to fix.
Does this mean the documentation at
<http://people.mech.kuleuven.be/~orocos/pub/documentation/ocl/v1.10.x/doc-xml/orocos-deployment.html>
is not correct and I should put something like
<struct name="Activity">
<simple name="Period" type="double"><value>0.005<value><simple>
<simple name="Priority" type="short"><value>0<value><simple>
<simple name="Scheduler" type="string"><value>ORO_SCHED_OTHER<value><simple>
<struct>
there (ie. without the activity type?)
I can't find anything in the orocos 1.10 changes either about this BTW.
>> The "Sx" components are all Simulink components running at the same frequency. Although the actual code seems to be running in a single thread (TimerThreadInstance2), 5 NonPeriodicThreads are created.
>
> They should have been cleaned up.
>
>
>>
>> Did we do something wrong or is this intended behaviour? And if the answer is: "the latter": are we then not wasting resources here and complicate the debugging process (the benefit of naming the thread after its component has completely disappeared it seems)?
>
> It's an issue we need to fix in the deployer.
>
> So I see two issues here:
>
> * Old thread is not cleaned up when new one is assigned.
> * TC Name is not passed during activity creation when using deployer.
>
> Correct ?
It seems to be at my setup at least. I guess it's hard to write a unit test that checks for the correct number of threads of an application?
thx,
Klaas
New 1.10 activity model creates useless threads?
On Thu, Nov 26, 2009 at 5:38 PM, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
> On Thu, 26 Nov 2009, Peter Soetens wrote:
>> On Thu, Nov 26, 2009 at 13:43, Klaas Gadeyne <klaas [dot] gadeyne [..] ...>
>> wrote:
[...]
>> You need to specify 'Activity' instead of 'PeriodicActivity' in your
>> deployer file. The behaviour is that if you specify an activity in
>> your deployment xml file, the current one is cleaned up and the new
>> one is installed. Unfortunately, the deployer does not yet assign the
>> component's name to the 'Activity', which is a one-liner to fix.
>
> Does this mean the documentation at
> <http://people.mech.kuleuven.be/~orocos/pub/documentation/ocl/v1.10.x/doc-xml/orocos-deployment.html>
> is not correct and I should put something like
>
> <struct name="Activity">
> <simple name="Period" type="double"><value>0.005<value><simple>
> <simple name="Priority" type="short"><value>0<value><simple>
> <simple name="Scheduler"
> type="string"><value>ORO_SCHED_OTHER<value><simple>
> <struct>
>
> there (ie. without the activity type?)
The answer seems to be "no", but from the sources I don't see why
PeriodicActivity would not be ok BTW?
A quick grep in deploymentComponent.cpp (ocl 1.10 branch) learns that
it should be the same?
// Read the activity profile if present.
if ( comp.value().find("Activity") != 0) {
Property<PropertyBag> nm =
comp.value().find("Activity");
if ( !nm.ready() ) {
log(Error)<<"Property 'Activity' must
be a 'struct'."<<endlog();
valid = false;
} else {
if ( nm.rvalue().getType() ==
"PeriodicActivity" || nm.rvalue().getType() == "Activity") {
Property
if
(nm.rvalue().getProperty<double>("Period") )
per =
nm.rvalue().getProperty<double>("Period"); // work around RTT 1.0.2
bug.
if ( !per.ready() &&
nm.rvalue().getType() == "PeriodicActivity") {
log(Error)<<"Please specify
period as <double> for "<< nm.rvalue().getType() <<endlog();
valid = false;
}
Klaas
>
New 1.10 activity model creates useless threads?
On Thu, Nov 26, 2009 at 6:02 PM, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
> On Thu, Nov 26, 2009 at 5:38 PM, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>> On Thu, 26 Nov 2009, Peter Soetens wrote:
>>> On Thu, Nov 26, 2009 at 13:43, Klaas Gadeyne <klaas [dot] gadeyne [..] ...>
>>> wrote:
> [...]
>>> You need to specify 'Activity' instead of 'PeriodicActivity' in your
>>> deployer file. The behaviour is that if you specify an activity in
>>> your deployment xml file, the current one is cleaned up and the new
>>> one is installed. Unfortunately, the deployer does not yet assign the
>>> component's name to the 'Activity', which is a one-liner to fix.
OK, use the source, luke. I guess you meant above: "You should use
Activity, since otherwise we won't be able to pass the components
name". Right?
k