Re: [Xenomai-help] Preemptive scheduling

[Philippe Gerum <rpm@xenomai.org>]

On Tue, 2007-04-03 at 22:55 +0200, Jack Whorn wrote:
> 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.
> 

Changeset r2092 introduced the sleeping scheduler lock for v2.3.x.

> 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.
> > 
> 
-- 
Philippe.