From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: xenoka09@domain.hid
Cc: Xenomai help <xenomai@xenomai.org>
Subject: Re: [Xenomai-help] POSIX skin, simple example with mutex not working...
Date: Thu, 23 Jul 2009 19:55:01 +0200 [thread overview]
Message-ID: <4A68A3F5.1000705@domain.hid> (raw)
In-Reply-To: <Pine.LNX.4.62.0907231741280.9450@domain.hid>
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
next prev parent reply other threads:[~2009-07-23 17:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-23 15:17 [Xenomai-help] POSIX skin, simple example with mutex not working Kolja Waschk
2009-07-23 15:30 ` Gilles Chanteperdrix
[not found] ` <Pine.LNX.4.62.0907231741280.9450@domain.hid>
2009-07-23 17:55 ` Gilles Chanteperdrix [this message]
2009-07-23 19:28 ` Kolja Waschk
2009-07-23 20:27 ` Philippe Gerum
2009-07-23 21:23 ` Philippe Gerum
2009-07-24 15:25 ` Kolja Waschk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A68A3F5.1000705@domain.hid \
--to=gilles.chanteperdrix@xenomai.org \
--cc=xenoka09@domain.hid \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.