scheduling - more doubts

Sudheer inbox1.sudheer at gmail.com
Mon Mar 14 02:24:59 EDT 2011


On Mon, Mar 7, 2011 at 10:09 AM, Sudheer <inbox1.sudheer at gmail.com> wrote:
> On Mon, Mar 7, 2011 at 9:42 AM, piyush moghe <pmkernel at gmail.com> 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 at wipro.com> 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



More information about the Kernelnewbies mailing list