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

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

[Kolja Waschk]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1155 bytes --]

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.

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

> 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:lock:1
> main:unlock:1
> thread:lock:1
> thread:unlock:1

Possibly I just missed some include file, compiler flag, .... or basic concept?

Thanks for any advice
Kolja

[-- Attachment #2: Type: TEXT/x-csrc, Size: 1379 bytes --]

#include <stdio.h>
#include <sys/mman.h>
#include <pthread.h>
#include <posix/posix.h>

static pthread_t task;

int try_mutex(const char *where);

void *body (void *unused)
{
    try_mutex("thread");

    pthread_exit(0);
}

int main (int argc, char *argv[])
{
    int r;
    pthread_attr_t attr;
    struct sched_param parm;

    mlockall(MCL_CURRENT|MCL_FUTURE);

    try_mutex("main");

    parm.sched_priority = 1;
    pthread_attr_init(&attr);
    pthread_attr_setinheritsched(&attr, 1);
    pthread_attr_setstacksize(&attr, 16384);
    pthread_attr_setschedparam(&attr, &parm);
    pthread_attr_setschedpolicy(&attr, SCHED_FIFO);

    r = pthread_create(&task, &attr, &body, NULL);
    if (r) printf("main:create:%d\n", r);

    r = pthread_join(task, 0);
    if (r) printf("main:join:%d\n", r);

    pthread_attr_destroy(&attr);

    return 0;
}

int try_mutex(const char *where)
{
    int r;
    pthread_mutex_t mx;
    pthread_mutexattr_t attr;
    pthread_mutexattr_init(&attr);

    r = pthread_mutex_init(&mx, &attr);
    if (r) printf("%s:init:%d\n", where, r);

    r = pthread_mutex_lock(&mx);
    if (r) printf("%s:lock:%d\n", where, r);

    r = pthread_mutex_unlock(&mx);
    if (r) printf("%s:unlock:%d\n", where, r);

    pthread_mutexattr_destroy(&attr);
    pthread_mutex_destroy(&mx);
}

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

[Gilles Chanteperdrix]

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

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

[Gilles Chanteperdrix]

Kolja Waschk wrote:
> Gilles,
> 
> thanks for the prompt answer. Yes, the code is not certainly not useful as a
> skeleton for building anything else...
> 
>> initialization has several defects:
>> - setinheritsched(1) does not mean anything (and actually, it would seem it
> 
> I copied it literally from the examples/posix/satch.c after I tried the
> PTHREAD_* macros, hoping that it might workaround a definition mismatch.
> 
>> 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.
> 
> Ah, I took that guess about main() not being realtime from some old
> conversation in Xenomai-help. Thanks for clarification.
> 
> https://mail.gna.org/public/xenomai-help/2006-06/msg00001.html
> 
>> So, in short, your example should work, everyone should return 0. There is a 
>> bug somewhere.
> 
> Fortunately, there's already an OS abstraction layer in the application,
> so it doesn't take long to replace POSIX mutex/sem/thread code with
> Xenomai native API calls, and this way it seems to work. Hm, I assume
> that mixing POSIX and native API calls is no good idea, or - for testing
> - is it safe to (e.g.) use POSIX calls for thread management and native
> API for mutexes? What about using POSIX clock_*() and native rt_mutex*
> side by side?

There is no real problem mixing the two APIs. For clock functions, 
rt_timer_tsc has less overhead than clock_*. Of course, if you use 
timeouts with rt_mutex, these can not be struct timespecs, you must 
recompose the 64 bits value.

However, I really think we whould fix this issue. Not having access to a 
blackfin, I will check if the error happens on my boxes, I think it does 
not happen, but there could be a recent regression. Also, do you observe 
the issue with a stable release of xenomai such as xenomai 2.4.8 ?

-- 
                                           Gilles

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

[Kolja Waschk]

Hi,

> However, I really think we whould fix this issue. Not having access to a

Sure, but I'm afraid I can't work much on it once I found one working
combination... I furthermore have strong problems using GDB here;
sometimes it doesn't halt at breakpoint main() but the program simply
runs over it and exits successfully, sometimes it segfaults or reboots.

> issue with a stable release of xenomai such as xenomai 2.4.8 ?

It seems to. At least the very same "try", when run on an older
uClinux-dist release from the Blackfin uClinux site (2008R1.5-RC3, with
Xenomai 2.4.0), returns zero from all mutex_lock attempts.

However, the app that I just converted to use the native API now returns
-1 from one particular rt_mutex_acquire :/ on the old dist, and
at some point reboots the target on the new...

Kolja

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

[Philippe Gerum]

On Thu, 2009-07-23 at 21:28 +0200, Kolja Waschk wrote:
> Hi,
> 
> > However, I really think we whould fix this issue. Not having access to a
> 
> Sure, but I'm afraid I can't work much on it once I found one working
> combination...

A sane combo for now should be 2.6.28.10, with
http://download.gna.org/adeos/patches/v2.6/blackfin/adeos-ipipe-2.6.28.10-blackfin.git-1.10-00.patch
on top of it, and Xenomai 2.4.8 stock.

> I furthermore have strong problems using GDB here;
> sometimes it doesn't halt at breakpoint main() but the program simply
> runs over it and exits successfully, sometimes it segfaults or reboots.
> > issue with a stable release of xenomai such as xenomai 2.4.8 ?
> 
> It seems to. At least the very same "try", when run on an older
> uClinux-dist release from the Blackfin uClinux site (2008R1.5-RC3, with
> Xenomai 2.4.0), returns zero from all mutex_lock attempts.
> 

2.4.0 is way too old; you may use any later Xenomai version with older
uClinux releases, we try hard to maintain backward compatibility.

If you want to run 2.6.30 kernels though, you will need the current tip
of our maintenance branch for the Xenomai 2.4.x series
(git://xenomai.org/xenomai-2.4.git), or something >= 2.5-rc2
(git://xenomai.org/xenomai-head.git).

> However, the app that I just converted to use the native API now returns
> -1 from one particular rt_mutex_acquire :/ on the old dist, and
> at some point reboots the target on the new...
> 

I confirm that we have a problem with 2.5-rc over blackfin, POSIX mutex
locking attempts do spuriously return EPERM as you reported. This does
not happen on 2.4.x (maintenance branch) with the same test kernel
(2.6.30); I'm suspecting an issue in our non-fastsync code, since 2.4
did not have this new Xenomai feature, and blackfin has it disabled for
now in 2.5. I'll have a look.

> Kolja
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

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

[Philippe Gerum]

On Thu, 2009-07-23 at 22:27 +0200, Philippe Gerum wrote:
> On Thu, 2009-07-23 at 21:28 +0200, Kolja Waschk wrote:
> > Hi,
> > 
> > > However, I really think we whould fix this issue. Not having access to a
> > 
> > Sure, but I'm afraid I can't work much on it once I found one working
> > combination...
> 
> A sane combo for now should be 2.6.28.10, with
> http://download.gna.org/adeos/patches/v2.6/blackfin/adeos-ipipe-2.6.28.10-blackfin.git-1.10-00.patch
> on top of it, and Xenomai 2.4.8 stock.
> 
> > I furthermore have strong problems using GDB here;
> > sometimes it doesn't halt at breakpoint main() but the program simply
> > runs over it and exits successfully, sometimes it segfaults or reboots.
> > > issue with a stable release of xenomai such as xenomai 2.4.8 ?
> > 
> > It seems to. At least the very same "try", when run on an older
> > uClinux-dist release from the Blackfin uClinux site (2008R1.5-RC3, with
> > Xenomai 2.4.0), returns zero from all mutex_lock attempts.
> > 
> 
> 2.4.0 is way too old; you may use any later Xenomai version with older
> uClinux releases, we try hard to maintain backward compatibility.
> 
> If you want to run 2.6.30 kernels though, you will need the current tip
> of our maintenance branch for the Xenomai 2.4.x series
> (git://xenomai.org/xenomai-2.4.git), or something >= 2.5-rc2
> (git://xenomai.org/xenomai-head.git).
> 
> > However, the app that I just converted to use the native API now returns
> > -1 from one particular rt_mutex_acquire :/ on the old dist, and
> > at some point reboots the target on the new...
> > 
> 
> I confirm that we have a problem with 2.5-rc over blackfin, POSIX mutex
> locking attempts do spuriously return EPERM as you reported. This does
> not happen on 2.4.x (maintenance branch) with the same test kernel
> (2.6.30); I'm suspecting an issue in our non-fastsync code, since 2.4
> did not have this new Xenomai feature, and blackfin has it disabled for
> now in 2.5. I'll have a look.
> 

That was indeed a fastsync related issue; here is a workaround on top of
2.5-rc2 that should bring your POSIX mutexes back to life. A better fix
will be merged later to xenomai-head.

diff --git a/ksrc/arch/blackfin/Kconfig b/ksrc/arch/blackfin/Kconfig
index a2208ef..47c3f4f 100644
--- a/ksrc/arch/blackfin/Kconfig
+++ b/ksrc/arch/blackfin/Kconfig
@@ -2,6 +2,11 @@ config XENO_GENERIC_STACKPOOL
 	bool
 	default y
 
+config XENO_NOFASTSYNCH
+	bool
+	default y
+	select XENO_OPT_REGISTRY
+
 source "kernel/xenomai/nucleus/Kconfig"
 
 menu "Machine"
diff --git a/ksrc/skins/posix/thread.c b/ksrc/skins/posix/thread.c
index 0d4977c..680bd85 100644
--- a/ksrc/skins/posix/thread.c
+++ b/ksrc/skins/posix/thread.c
@@ -269,7 +269,6 @@ int pthread_create(pthread_t *tid,
 	thread->hkey.mm = NULL;
 #endif /* CONFIG_XENO_OPT_PERVASIVE */
 
-#ifdef CONFIG_XENO_FASTSYNCH
 	/* We need an anonymous registry entry to obtain a handle for fast
 	   mutex locking. */
 	{
@@ -279,7 +278,6 @@ int pthread_create(pthread_t *tid,
 			return ret;
 		}
 	}
-#endif /* CONFIG_XENO_FASTSYNCH */
 
 	*tid = thread;		/* Must be done before the thread is started. */
 

> > Kolja
> > 
> > 
> > 
> > _______________________________________________
> > Xenomai-help mailing list
> > Xenomai-help@domain.hid
> > https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

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

[Kolja Waschk]

Philippe,

> That was indeed a fastsync related issue; here is a workaround on top of
> 2.5-rc2 that should bring your POSIX mutexes back to life. A better fix

Thanks for the very quick fix! Your patch solves my issue with
pthread_mutex_lock(). I'm still having problems with the POSIX skin but
that'll be a topic of separate postings.

Kolja