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.

> 
> Regards,
> Thomas
> 
> 
> 
-- 
Philippe.



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

Reply via email to