Messages in this thread | | | From | "Arthur Naseef" <> | Subject | RE: Kernel 2.2: tq_scheduler functions scheduling and waiting | Date | Tue, 29 May 2001 21:16:34 -0400 |
| |
I have tested with a kernel thread running the tq_scheduler and it is much more stable. The kernel still ran into a problem in n_tty.c in which the compiler optimized-out the check "if (!tty)" in n_tty_set_termios(); I am still investigating the right solution to this.
As a long term fix, I will review the 2.4 and latest 2.2 sources.
> Yes. The situation where one task is on two waitqueues > is rare, but does happen. And yes, there is code out there > which does a bare schedule() and *assumes* that once the > schedule has returned, the thing it was waiting for has > indeed occurred. > > Generally this is poor practice - it's safer to loop > over the schedule() call until the condition you're > sleeping on has been tested.
I see your point. It would prevent this type of problem if all code waiting for conditions made certain those conditions were met. However, given the way the kernel works, it is not necessary to check unless the task specifically expects more than one condition to awaken it - at least it wasn't until tq_scheduler was introduced. Actually, that is not fair either - only when functions in tq_scheduler starting "blocking" did this become a problem.
It would help me tremendously if these types of limitations and requirements for working in the kernel were well documented. It takes significant effort to determine the requirements, and to verify that my understanding is correct.
> > You really shouldn't be sleeping in this way on tq_scheduler > if there's any way in which the sleep can take an extended > period of time. You may end up putting important kernel > tasks to sleep.
I agree. In addition, even if the tq_scheduler function did check for its own condition, a problem still exists when the task returns to the code using the first wait queue before its condition is met; since the code using the second wait queue would set the task state to running and would not set it back (which it couldn't without knowing the conditions to check).
> > Best to use schedule_task(), or an independent kernel thread. > > - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |