On Mon, 2007-01-29 at 17:41 +0100, Markus Osterried wrote:
> Hi Philippe,
>
> see below a code snippet for demonstration of the task priority problem.
> The expected behaviour is that the new task is running immediately after
> lowering root's priority.
> The log of the reached statements should t
Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
In short, the following patch against 2.3.0 stock fixes the issue,
allowing threads to block while holding the scheduler lock.
>>> Ok, but this means that the skins which use XNLOCK with the previous
>>> meaning need fixing.
>>>
>>
>> O
On Wed, 2007-01-31 at 10:28 +0100, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> >>>In short, the following patch against 2.3.0 stock fixes the issue,
> >>>allowing threads to block while holding the scheduler lock.
> >>
> >>Ok, but this means that the skins which use XNLOCK with the previ
Philippe Gerum wrote:
>>>In short, the following patch against 2.3.0 stock fixes the issue,
>>>allowing threads to block while holding the scheduler lock.
>>
>>Ok, but this means that the skins which use XNLOCK with the previous
>>meaning need fixing.
>>
>
>
> Only those which really wanted - i.
On Wed, 2007-01-31 at 09:55 +0100, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Mon, 2007-01-29 at 14:25 +0100, Gilles Chanteperdrix wrote:
> >
> >>Philippe Gerum wrote:
> >>
> >>>On Fri, 2007-01-26 at 18:16 +0100, Thomas Necker wrote:
> >>>
> >>>
> So it clearly states that a no
Philippe Gerum wrote:
> On Mon, 2007-01-29 at 14:25 +0100, Gilles Chanteperdrix wrote:
>
>>Philippe Gerum wrote:
>>
>>>On Fri, 2007-01-26 at 18:16 +0100, Thomas Necker wrote:
>>>
>>>
So it clearly states that a non-preemtible task may block (and
rescheduling occurs in
this case).
>>>
On Mon, 2007-01-29 at 17:41 +0100, Markus Osterried wrote:
> Hi Philippe,
>
> see below a code snippet for demonstration of the task priority problem.
> The expected behaviour is that the new task is running immediately after
> lowering root's priority.
> The log of the reached statements should t
On Mon, 2007-01-29 at 14:25 +0100, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Fri, 2007-01-26 at 18:16 +0100, Thomas Necker wrote:
> >
> >>So it clearly states that a non-preemtible task may block (and
> >>rescheduling occurs in
> >>this case).
> >
> >
> > Ok, so this is a must
Hi Philippe,
see below a code snippet for demonstration of the task priority problem.
The expected behaviour is that the new task is running immediately after
lowering root's priority.
The log of the reached statements should therefor be: 1, 10, 2, 3, 4, 5
But instead the log is: 1, 2, 3, 4, 10,
On Mon, 2007-01-29 at 14:25 +0100, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Fri, 2007-01-26 at 18:16 +0100, Thomas Necker wrote:
> >
> >>Hi Philippe
> >>
> >>
> non-preemptive mode.
> With original pSOS this was allowed and "non-preemptive" meant that a
> runnable tas
Philippe Gerum wrote:
> On Fri, 2007-01-26 at 18:16 +0100, Thomas Necker wrote:
>
>>Hi Philippe
>>
>>
non-preemptive mode.
With original pSOS this was allowed and "non-preemptive" meant that a
runnable task cannot be preempted by other tasks but can block itself.
Why is this differ
On Fri, 2007-01-26 at 18:16 +0100, Thomas Necker wrote:
> Hi Philippe
>
> > > non-preemptive mode.
> > > With original pSOS this was allowed and "non-preemptive" meant that a
> > > runnable task cannot be preempted by other tasks but can block itself.
> > > Why is this different in Xenomai and is
Hi Philippe
> > non-preemptive mode.
> > With original pSOS this was allowed and "non-preemptive" meant that a
> > runnable task cannot be preempted by other tasks but can block itself.
> > Why is this different in Xenomai and is it possible to implement the
same
> > behaviour in Xenomai core?
>
On Fri, 2007-01-26 at 15:34 +0100, Markus Osterried wrote:
> Hello,
>
> I work together with Thomas Necker on a legacy pSOS project to get it
> ported to Xenomai.
> I have already ported a great amount of code and most of it works fine.
>
> But we have a pSOS task which (sometimes) works in non-p
Hello,
I work together with Thomas Necker on a legacy pSOS project to get it
ported to Xenomai.
I have already ported a great amount of code and most of it works fine.
But we have a pSOS task which (sometimes) works in non-preemptive mode
(T_NOPREEMPT).
When this task calls ev_receive() it gets b
15 matches
Mail list logo
