Hi,
here is the latest attempt to avoid entering __xnpod_schedule when
xnpod_unlock_sched is called without a needed rescheduling.
This one is much simpler. We do not try to prevent entering
__xnpod_schedule when xnpod_schedule is called with the scheduler
locked: it may be racy when the current thread wants to suspend with the
scheduler locked, and would avoid sending the reschedule IPIs to other
cpus if the other cpus scheduler state was changed. Instead, if
xnpod_schedule is called with the scheduler locked, but not to suspend
the current thread, exit early keeping the resched bit set. This avoids
having to set the resched bit in xnpod_unlock_sched and thus entering
__xnpod_schedule every time.
As with the previous patch, no attempt is made to lock the scheduler for
the implementation of xnlock* services, as they are called at a time
during the early init where xnpod_current_thread() is NULL.
Regards.
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
