On Mon, Mar 7, 2011 at 10:09 AM, Sudheer <inbox1.sudheer@xxxxxxxxx> wrote: > On Mon, Mar 7, 2011 at 9:42 AM, piyush moghe <pmkernel@xxxxxxxxx> wrote: >> Hi Sudheer, >> If you see there is a schedule_timeout function called with some timeout >> so if you receive any signal ( handled by apm_event_handler ) before the >> timeout value it will be woken up and if it receives no signal before >> timeout value than scheduler will move this to RUNNABLE state again. >> Regards, >> Piyush >> >> On Thu, Mar 3, 2011 at 5:20 PM, <sudheer.divakaran@xxxxxxxxx> wrote: >>> >>> Hi, >>> >>> I had asked a similar question before, but I've some doubts regarding the >>> correctness of the following code. Please see the following code snippet >>> from the file linux-2.6.37/arch/x86/kernel/apm_32.c. This is the core >>> function of apm thread. >>> >>> >>> Question: >>> Suppose the apm thread has just completed execution of the line 1442 and >>> the scheduling happens for some reason, AFAIK, since the apm thread's state >>> has been set to TASK_INTERRUPTIBLE, it will be removed from the run-queue. >>> So there is a chance for the apm thread to remain suspended indefinitely as >>> nobody is there to wakeup the apm thread, correct? >>> >>> I'm asking this because the same function has been given as an example in >>> the following link and would like to confirm the accuracy of the example. >>> >>> http://www.linuxjournal.com/node/8144/print >>> >>> >>> >>> 1437 static void apm_mainloop(void) >>> 1438 { >>> 1439 DECLARE_WAITQUEUE(wait, current); >>> 1440 >>> 1441 add_wait_queue(&apm_waitqueue, &wait); >>> 1442 set_current_state(TASK_INTERRUPTIBLE); >>> 1443 for (;;) { >>> 1444 schedule_timeout(APM_CHECK_TIMEOUT); >>> 1445 if (kthread_should_stop()) >>> 1446 break; >>> 1447 /* >>> 1448 * Ok, check all events, check for idle (and mark us sleeping >>> 1449 * so as not to count towards the load average).. >>> 1450 */ >>> 1451 set_current_state(TASK_INTERRUPTIBLE); >>> 1452 apm_event_handler(); >>> 1453 } >>> 1454 remove_wait_queue(&apm_waitqueue, &wait); >>> 1455 } >>> >>> >>> -- >>> Thanks, >>> Sudheer >>> > > > Hi, > My question was the apm thread getting scheduled out of run queue at > apm_32.c line no 1443. > i.e., for(;;), just after executing the line 1442, i.e., > > set_current_state(TASK_INTERRUPTIBLE); > > In this case, AFAIK, schedule_timeout(APM_CHECK_TIMEOUT) will not be > executed as the apm thread will not be returned to the run queue. > CMIIW. > > -- > Thanks > Sudheer > Hi, I did some more googling and found a similar thread http://fixunix.com/linux/7425-schedule_timeout-doubt-possible-infinite-sleep.html quoting from the link, [quote-] If I understand it correctly, when a preemption occurs, the PREEMPT_ACTIVE bit gets added to the thread's preempt_count; this happens in preempt_schedule / preempt_schedule_irq. These then call schedule(), which checks for PREEMPT_ACTIVE being set in the count and if it's set, it *doesn't* call deactivate_task(), which leaves the thread on the active list. [-quote] So if an interrupt occurs, the thread will not be pre-empted since the PREEMPT_ACTIVE bit has been set. I was not sure about the PREEMPT_ACTIVE bit. -- Thanks Sudheer _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
