Kolja Waschk wrote:
> Hi,
>
> As a newcomer to Xenomai, I was until now successfully experimenting
> with the native skin. Now that it comes to run an existing application
> that is written for POSIX threads, a few problems show up. The
> pthread_mutex_lock() _always_ returns 1 (EPERM) to me, although there
> are no forks involved and policy should have been to SCHED_FIFO.
Setting the policy to SCHED_FIFO is not necessary. However, your thread
initialization has several defects:
- it does not check the return values of the function it calls, so you
do not see the errors which follow
- setinheritsched(1) does not mean anything (and actually, it would seem
it means the contrary of what you would like, but I can not say for
sure), you should use the constants PTHREAD_EXPLICIT_SCHED or
PTHREAD_INHERIT_SCHED
- setting the priority to anything else than 0 in the thread creation
attributes only works once you have set the scheduling policy (at least
it did a long time ago with linuxthreads, and I guess you are using
linuxthreads).
>
> If that's of interest, I'm developing for a Blackfin uClinux (NOMMU)
> target with newest uClinux-dist snapshot (Kernel
> 2.6.30.2-ADI-2010R1-pre, Xenomai 2.4.91, Nucleus v2.5-rc2) with FDPIC
> userland. For building, I simply used
Yes, that is of interest, because I do not think we experience this
issue on other platforms.
>
>> bfin-linux-uclibc-gcc `/usr/xenomai/bin/xeno-config --posix-cflags`
>> `/usr/xenomai/bin/xeno-config --posix-ldflags` try.c -o try
>
> Writing an explicit command line including the -Wl,@(wrapper) etc.
> doesn't change anything. The output of the attached code, compiled,
> shows the return value from mutex_lock, first called from the NRT
> main(), then from a thread that IMHO should run as a realtime thread:
main is a real-time thread. All threads are real-time threads, whatever
the scheduling policy you use. The only way to create a non real-time
thread is to call __real_pthread_create.
So, in short, your example should work, everyone should return 0. There
is a bug somewhere.
--
Gilles
_______________________________________________
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
