Hi all... Sorry for coming late.... On Wed, Nov 19, 2008 at 8:16 PM, dinesh bansal <bansal.dk@xxxxxxxxx> wrote: > As I understand the problem, process has set the state to TASK_INTERRUPTIBLE > but its still in run queue (since schedule() has not been called). Now if > this process gets interrupted (by higher priority process I suppose), its > current state will be saved, and new process will be executed. Since our > process is in runqueue still, it will be reschedule again after some time. > Since while rescheduling, scheduler does not check the status bit, these > will be no effect of this TASK_INTERRUPTIBLE status bit. And just after > getting rescheduled, process is going to sleep (call schedule()) again. > Please let me know if my understanding is correct. I agree with Dinesh's opinion. However, I'd like to add further opinions: assume that process is going to be interrupted by a interrupt handler. Let's name the process task A. A is then halted while still in run queue. Interrupt handler is finished, then it walks through ret_from_intr. Also assume that kernel level preemption is enabled. Then the scheduler picks task B. B runs 'til its time slice is completely taken. Scheduler picks A again. Then A runs right when it's going to execute schedule(), thus forcing voluntary scheduling. My point here is: if there's scheduling happen before we hit schedule(), there's a chance we come to two sucessive scheduling from task A's point of view. Or in other word, we sleep longer than predicted. IIRC, before we set a task into interruptible state, we usually made it into wait queue. Thus when another task wants to wake up it, it just tells "wake up the process that sits on this list". So maybe, the code fragment Nidhi's originally showed might be incomplete. NB: I like your quote Dinesh, it certainly applies to our discussion here. regards, Mulyadi. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
