On 12/07/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  >
>  > -  if (xnpod_unblockable_p()) {
>  > +  if (xnpod_locked_p()) {
> Why not if (task == xeno_current_task() && xnpod_unblockable_p()) ?

Is it legal to suspend a foreign task when XNLOCK is set? If yes, I
would vote for your version as well.

You mean if the current task holds XNLOCK and wanna suspend another task -> which, in turn, seemingly implies some "scheduling" action?

The only (probably) idea behind XNLOCK is to avoid rescheduling for as long as the current task (on this scheduler) locks the scheduler.

So it disallows _rescheduling_ but any actions like manipulating e.g. the list of active tasks should still remain allowed. One may recall preempt_enable/disable() in Linux.

(ummm... actually, xnpod_thread_mode() doesn't seem to cause re-scheduling in case of removing the lock as it's done by xnpod_unlock_sched())

Moreover, we have per-cpu schedulers so that a task that locks the scheduler on cpu0 may still suspend (and cause re-scheduling) of any really running task on another cpu (or it likely should be so :)

So I don't see any problem here. Sure I don't know all the implementation details and can be just driven by my own misunderstanding.


Best regards,
Dmitry Adamushko
Xenomai-core mailing list

Reply via email to