lkml.org 
[lkml]   [1999]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.214 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site