Re: [Xenomai-help] POSIX skin, simple example with mutex not working...

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

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