Mani, On Tue, Apr 17, 2012 at 1:35 PM, mani <manishrma@gmail.com> wrote:
Thanks Philipp for the explanation and the link.
But i Still have the same question:-
Do scheduler schedule the tasks with TASK_INTERRUPTIBLE state ? As i know TASK_UNINTERRUPTIBLE & TASK_INTERRUPTIBLE both are not in the run queue and so both type of tasks should not being scheduled by the scheduler. If YES, then why it is needed to schedule task in TASK_INTERRUPTIBLE state ?
think of a signal as a software interrupt. If your thread is in the TASK_INTERRUPTIBLE state, it can be woken up by such software interrupt handlers in order to deliver the signal to your thread. Your thread will then be put into the runqueue ( and state will be TASK_RUNNING) and your wait_event_interruptible() call will return with the value -ERESTARTSYS. This is for you to be able to react to the delivered signal (you can read the active signals using signal_pending(current)). So, to answer your question: Yes, your thread will be put back into the runqueue, if you mark it as TASK_INTERRUPTIBLE and a signal is delivered to your thread. Your thread will _not_ be interrupted by software interrupts/signals when you mark it as TASK_UNINTERRUPTIBLE.
What is the significance of the task->switch_count in the scheduler ? surely it got updated for the TASK_INTERRUPTIBLE task. [kernel/hung_task.c]check_hung_task()
You can see in the same source file that check_hung_task() is called by check_hung_uninterruptible_tasks(). But the function check_hung_task() is only called for tasks which are in the state TASK_UNINTERRUPTIBLE: if (t->state == TASK_UNINTERRUPTIBLE) check_hung_task(t, timeout); The t->last_switch_count counts the number of switches since the last call to check_hung_task() (the value is only updated there). I hope this answers your questions. Greetings, Philipp