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 
> > 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 
    One bit controls the task's preemptibility. If disabled, then once the 
    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).


Xenomai-core mailing list

Reply via email to