On Fri, 23 Mar 2018 13:21:31 -0400 joe.korty@xxxxxxxxxxxxxxxxx wrote: > My understanding is, in standard Linux and in rt, setting > task state to anything other than TASK_RUNNING in of itself > blocks preemption. That is clearly false. The only thing that blocks preemption with a CONFIG_PREEMPT kernel is preempt_disable() and local_irq*() disabling. (Note spin_locks call preempt_disable in non RT). Otherwise, nothing will stop preemption. > A preemption is not really needed here > as it is expected that there is a schedule() written in that > will shortly be executed. And if a 'involuntary schedule' > (ie, preemption) were allowed to occur between the task > state set and the schedule(), that would change the task > state back to TASK_RUNNING, which would cause the schedule > to NOP. Thus we risk not having paused long enough here > for the condition we were waiting for to become true. That is also incorrect. As Julia mentioned, a preemption keeps the state of the task. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
