Re: Scheduler: Spinning until tasks are STOPPED

[Yuly Finkelberg <liquidicecube@gmail.com>]

> Well it still sounds like the kernel is doing too much. For example,
> why don't you just have a syscall (or char device) just to send out
> the events, and do everything else (all the queueing and
> synchronisation and signalling) in userspace?

True, it does :)
However, the operation requires that a consistent in-kernel state will
hold for the tasks.  They all (except for the last one) do some work,
send a SIGSTOP to themselves, and return to usermode (handling the
STOP signal).  The last task does not stop itself, but instead
verifies that all of the others are stopped before it returns.

> OK, for a simple example, instead of spinning on yield(), do a
> down() on a locked mutex.
> Then have maybe an `atomic_t nr_running` which is incremented for
> each worker task running. When they are ready to stop, they can
> do an atomic_dec_and_test of nr_running, and the last one can up()
> the mutex. If you absolutely need to know when the process is
> actually stopped, why?

I need to ensure that the internal state of the processes will not
change (unless of course some other signal gets delivered, which will
not be the case).

It doesn't look like the problem is with the task that is spinning
until the others have stopped.  Instead, it looks like one of the
other tasks is spinning somewhere in between the time that it wakes up
its successor and the time that it sends it self the STOP signal.  It
is clearly getting preempted but then makes no progress (sometimes for
a VERY long time).