[Xenomai-help] What happens if task entry function returns?

[Xenomai-help] What happens if task entry function returns?

[M. Koehrer]

[-- Attachment #1.1: Type: text/plain, Size: 1450 bytes --]

Hi!

I am just playing around with Xenomai to understand it.
And I have one question concerning the entry function that will be called from
rt_task_start (Native API).
What happens if this entry function reaches its end or a return within the function is
called?

I have made a simple example that lead to strange effects.
In my example (see complete C Code in attachement) I create to tasks
that do the same.
The entry functions look like:

void taska(void *cookie)
{
    RTIME delay;
    int i;
    printf("Hi, I am task A %s\n", (char*)cookie);
    delay = 100000;

    for (i=0; i<200; i++)
    {
        rt_task_sleep(delay);
    }

    printf("This is the end of A\n");
    // rt_task_delete(0);
}
When I do not place the rt_task_delete(0) at the end of the function
my second task will never reach the end with the second printf.
Whenever I use rt_task_delete(0) at the end of the function it works perfectly.

My question is now: What happens if the task's entry function returns?

Thanks for any feedback on that question.

Regards

Mathias


-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  44,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

[-- Attachment #2: multitasks.c.gz --]
[-- Type: application/postscript, Size: 562 bytes --]

[Xenomai-help] Re: What happens if task entry function returns?

[Jan Kiszka]

M. Koehrer wrote:
> Hi!
> 
> I am just playing around with Xenomai to understand it.
> And I have one question concerning the entry function that will be called from
> rt_task_start (Native API).
> What happens if this entry function reaches its end or a return within the function is
> called?
> 
> I have made a simple example that lead to strange effects.
> In my example (see complete C Code in attachement) I create to tasks
> that do the same.
> The entry functions look like:
> 
> void taska(void *cookie)
> {
>     RTIME delay;
>     int i;
>     printf("Hi, I am task A %s\n", (char*)cookie);
>     delay = 100000;
> 
>     for (i=0; i<200; i++)
>     {
>         rt_task_sleep(delay);
>     }
> 
>     printf("This is the end of A\n");
>     // rt_task_delete(0);
> }
> When I do not place the rt_task_delete(0) at the end of the function
> my second task will never reach the end with the second printf.
> Whenever I use rt_task_delete(0) at the end of the function it works perfectly.

Quite inconsistent, sounds like a bug. Does the second rt_task_join just
rush through and main terminates?

> 
> My question is now: What happens if the task's entry function returns?

pthread_exit() is invoked implicitly, which implies rt_task_delete(NULL).

> 
> Thanks for any feedback on that question.

Is this issue SMP-related? What happens if you force all your tasks to
the same CPU? Or if you run on a !CONFIG_SMP box?

Jan

[Xenomai-help] Re: What happens if task entry function returns?

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]

M. Koehrer wrote:
> Hi Jan, 
> 
> I found out, that is issue seems to be related to the NPTL (native posix thread library).
> The pthread library in use was 
> /lib/tls/i686/cmov/libpthread.so.0
> which is part of the Debian (testing) package libc6-i686.
> (see http://packages.debian.org/testing/libs/libc6-i686)
> 
> When renaming the lib/tls to lib/tls.disabled the pthread library in use is
> /lib/libpthread.so.0
> and then it is working perfectly!

...which does not yet explain WHY the other scenario fails.

> 
> It seems that the i686 optimized libc is not fully compatible with Xenomai.

That's not true in such a common form. We are using NTPL libs for i586
and i686 (SuSE builds) without /general/ issues. Still, specific
problems like this may sleep somewhere.

> I read about this library at Romain Lenglet's web page:
> http://www.csg.is.titech.ac.jp/~lenglet/howtos/realtimelinuxhowto/index.html
> I think this library uses the NPTL (Native Posix Thread Lib).
> The i686 optimized library shows the value
> NPTL 2.3.6  
> at 
> getconf GNU_LIBPTHREAD_VERSION
> The "old" pthread lib shows the value:
> linuxthreads-0.10
> 
> Now, I tried to reconfigure Xenomai with --enable-x86-sep to use
> the NPTL but this did not help either.

That only influences the way syscalls are passed down into the kernel.

> When I rename now  /lib/tls to /lib/tls.disabled, the application complains
> about the missing NPTL support in the library.
> Well, I have now a solution that works:
> I can use the standard pthread lib and not the i686 optimized NPTL.
> However, as NPTL seems to be a performance benefit, I think it could be
> worth to get this combination up and running.
> 
> Is there anybody out there that uses a Debian based system with the i686
> optimized libc that works perfectly?
> 
> BTW: I am using xenomai 2.2.4 from end of October.
> 

Again my question: is the issue SMP related?

Reproducing your problem over a qemu box (with or without SMP) failed so
far for me. But I'm not on your glibc.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]