On Monday 09 February 2009 16:56:40 Himanshu Chauhan wrote: > On Mon, 2009-02-09 at 21:16 +0700, Mulyadi Santosa wrote: > > Hi... > > > > On Mon, Feb 9, 2009 at 2:57 PM, <sudheer.divakaran@xxxxxxxxx> wrote: > > > Hi All, > > > Please look at the following code from the article Sleeping in the > > > Kernel > > > > > > http://www.linuxjournal.com/node/8144/print > > > > > > 1 set_current_state(TASK_INTERRUPTIBLE); > > > 2 spin_lock(&list_lock); > > > 3 if(list_empty(&list_head)) { > > > 4 spin_unlock(&list_lock); > > > 5 schedule(); > > > 6 spin_lock(&list_lock); > > > 7 } > > > 8 set_current_state(TASK_RUNNING); > > > 9 > > > 10 /* Rest of the code ... */ > > > 11 spin_unlock(&list_lock); > > > > > > > > > Is there any chance for the process getting scheduled out of the > > > > run-queue > > > > > at Line# 2 (say the scheduler runs because of timer interrupt)?? > > I don't think schedule() will put you off the runqueue. And I don't see > the reason also. You didn't call sleep, neither are you doing any IO > request or anything else that can put you off the runqueue. Schedule() > is not supposed to put you off. But I might be wrong! schedule won't put you off the run-queue (state will remain TASK_RUNNING), but it *may* pre-empt you, i.e. pick another task from the queue (and insert current into the queue). You may, AFAIK, be pre-empted twice in this scenario, first on return from a possible interrupt (let's say a timer-interrupt happens whilst spinning for the lock), and then again at schedule(). If so, it is still fair, as other tasks are in graver need for running than current, and should be allowed to run anyway. > - Himanshu -- -> henrik -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
