From: "Jack Whorn" <jackwhorn@domain.hid>
To: rpm@xenomai.org
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] Preemptive scheduling
Date: Tue, 03 Apr 2007 22:55:54 +0200 [thread overview]
Message-ID: <20070403205554.107880@domain.hid> (raw)
In-Reply-To: <1175631875.22950.72.camel@domain.hid>
Hi Philippe,
thank you for this suggestion!
You are right, I`m still using version 2.3. This is due to some adjustments I have made in the Xenomai Sources which prevent me from simply overwriting the old files.
I have just locked at the source-code, the only occasion I use T_LOCK is in the rt_task_set_mode() call, used as the first argument (clear mask!). So there should not be a T_LOCK at all.
Nevertheless, if anybody could provide me with the appropriate positions in Xenomai`s source code, I might apply this bugfix manually and find out whether the problem is solved this way.
Thank you very much,
Jack
-------- Original-Nachricht --------
Datum: Tue, 03 Apr 2007 22:24:35 +0200
Von: Philippe Gerum <rpm@xenomai.org>
An: Jack Whorn <jackwhorn@domain.hid>
CC: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>, xenomai@xenomai.org
Betreff: Re: [Xenomai-help] Preemptive scheduling
> On Tue, 2007-04-03 at 22:05 +0200, Jack Whorn wrote:
> > Hi Gilles, Hi folks,
> >
> > The data is stored by a thread that periodically issues a single call to
> > rt_task_set_mode(0, T_PRIMARY, NULL) followed by several file operation
> calls like fprintf() and finally a call to fflush(NULL) and sync().
> >
> > The application is not a kernel module, so - as far as I see it - it is
> a user mode thread, and it actually has the highest priority in my system.
> >
> > Does this help understanding the phenomenon?
> >
>
> This whole thing reminds me of an issue involving T_LOCK that existed
> for any version earlier than 2.3.1. The way the scheduler lock (i.e.
> T_LOCK) was managed at that time would cause unexpectable results (aka
> "utter mess") to happen whenever a scheduler lock holder thread switches
> to secondary mode, and thinking about it, this would surely cause a
> lockup due to a scheduling wreckage. This has been fixed on January 30,
> by allowing the currently running thread which holds the scheduler lock
> to sleep.
>
> You may want to try 2.3.1 to check this.
>
> --
> Philippe.
>
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
next prev parent reply other threads:[~2007-04-03 20:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-28 20:31 [Xenomai-help] Preemptive scheduling Jack Whorn
2007-03-28 21:20 ` Gilles Chanteperdrix
2007-03-29 3:17 ` Jack Whorn
2007-03-29 8:46 ` Gilles Chanteperdrix
2007-04-03 20:05 ` Jack Whorn
2007-04-03 20:24 ` Philippe Gerum
2007-04-03 20:55 ` Jack Whorn [this message]
2007-04-04 8:17 ` Philippe Gerum
2007-04-04 15:10 ` Jack Whorn
2007-04-05 18:38 ` Philippe Gerum
2007-04-10 22:47 ` Jack Whorn
2007-04-11 8:15 ` Dmitry Adamushko
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=20070403205554.107880@domain.hid \
--to=jackwhorn@domain.hid \
--cc=rpm@xenomai.org \
--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.