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
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).
Ok, so this is a must fix.
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 non-preemtible task may block
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.e. by design -
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 previous
meaning
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.
Only those which
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 fix. Will do.
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 different in Xenomai and is it
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 task cannot be preempted by other
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 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
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?
Xenomai
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 it possible to
13 matches
Mail list logo
