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 tasks but can block itself.
> >>>>Why is this different in Xenomai and is it possible to implement the 
> >>
> >>same
> >>
> >>>>behaviour in Xenomai core?
> >>>>
> >>>
> >>>Xenomai implements the non-preemptible mode as most RTOSes implement
> >>>scheduling locks. From this POV, allowing a non-preemptible task to
> >>>block makes no sense, and doing so usually either locks up the board, or
> >>>causes an API error.
> >>>
> >>>It could be possible to switch the preemption bit on before entering a
> >>>blocking state only for pSOS tasks, then reinstate it when the task
> >>>wakes up, though. However, before going down that path, is there any
> >>>pSOS documentation that clearly states that such behaviour is to be
> >>>expected (i.e. that blocking calls _may_ be called in non-preemptible
> >>>mode)?
> >>>
> >>>Or did you benefit from an undocumented and fortunate side-effect of the
> >>>pSOS implementation when relying on such behaviour?
> >>
> >>Since Markus has already left, I had a quick look in the pSOS System 
> >>Concepts Manual:
> >>
> >>    Each task has a mode word, with two settable bits that can affect 
> >>scheduling.
> >>    One bit controls the task's preemptibility. If disabled, then once the 
> >>task
> >>    enters the running state, it will stay running even if other tasks
> >>    of higher priority enter the ready state. A task switch will occur 
> >>only if
> >>    the running task blocks, or if it re-enables preemption.
> >>
> >>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. Thanks for reporting.
> 
> I had a look at the OSEK specification, it also has non-preemptible
> tasks. So, I guess we should add an xnpod_locked_schedule that simply does
> 
> if (xnthread_test_state(xnpod_current_sched()->runthread, XNLOCK)) {
>       xnpod_unlock_sched();
>       xnpod_lock_sched();
> } else
>       xnpod_schedule();
> 
> and call this xnpod_locked_schedule() instead of xnpod_schedule() in
> these skins.

Ack, would do. Thomas, could you confirm that the preemptible bit is
raised again for the task when it is scheduled back in?

> 
> 
> 
> 
-- 
Philippe.



_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to