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). Regards, Thomas _______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core