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

["M. Koehrer" <mathias_koehrer@domain.hid>]

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!

It seems that the i686 optimized libc is not fully compatible with Xenomai.
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.
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.

Thanks for any feedback on this

Mathias
> > 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
> 

-- 
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