Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Thu, 17 Jun 1999 12:55:13 +0100 (BST) | Subject | Re: reschedule_idle |
| |
Hi,
On Wed, 16 Jun 1999 20:02:05 +0200 (CEST), Andrea Arcangeli <andrea@suse.de> said:
> On Wed, 16 Jun 1999, Stephen C. Tweedie wrote: >> Umm, check the stock definition of related(): if the two tasks are >> related then we know for sure that they both want the kernel lock. We >> cannot possibly find a related task if there is only one task waiting >> for the global lock.
> If the only two tasks in the system that wants the kernel lock are the > wakenup task and the current-running task, then rescheduling the wakenup > task in _place_ of the current task will work _fine_. There _won't_ be any > contention of the lock simply because the current task will go offline > waiting the next schedule sleeping in the _run_queue.
That one very special case. What about doing a wakeup from a signal handler? Or pipes? In the general case, you cannot assume that the current process is about to give up its lock: you can only do that when the current task state is not TASK_RUNNING.
--Stephen
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |