as far as i know
1:set_current_state (TASK_INTERRUPTIBLE)
2:schedule()

statement 1 only changes the state variable in task_struct doesnt put the
process to sleep
so after statement 1 the process is in a state where its state is
task_interruptible but its not out of runqueue.

then when scahedule is called
it takes decison like this.
if the process state is TASK_INTERRUPTIBLE it put the process to sleep takes
it out of runqueue.
but if its state is TASK_RUNNIG and schedule is called its not put out of
runqueue only scheduled out for some time.
these are correct statements  according to this article
http://www.linuxjournal.com/article/8144



so please now consider my ques ...






On Fri, Nov 14, 2008 at 10:31 PM, sahlot arvind <[EMAIL PROTECTED]> wrote:

> Well I think during context switch [schedule()] we disable interrupts and
> thus there is no point of corruption.
> Anyway specific to your query,
>
> actually i saw that ..
> set_current_state (TASK_INTERRUPTIBLE)
> schedule()
>
> I guess there must be some sort of locking etc. if you can locate me in the
> code (which file, lines etc) it would be more helpful.
>
> now my ques is
> if process is interrupted between these two statements by any means......
> wont it be in some corrupt state
> where its not sleeping but running but its state is changed to
> TASK_INTERRUPTIBLE............
>
> Assuming, as you said these two statements are independent. Suppose A is
> running and set_current_state is called in A's context, A's state will
> change to TASK_INTERRUPTIBLE, then we get interrupted then the code, which
> actually wakes up the sleeping processes will change the state of A again to
> TASK_RUNNING (i dont remember the exact macro name). So when schedule ()
> will be called (maybe from code, which wakes up the sleeping processes or
> somewhere else), depending upon sched algo, A might get a chance to run
> again and note that the state is RUNNING and task would also be running or
> maybe lined up in running queue. ==> no  corruption.
>
> and in 2nd statement we put process to actual sleep
>
> Also note that schedule() simply picks up the most suitable task to run and
> does not make any process sleeping.
>
> Hope that helps and let me know if I am wrong.
>
> Best regards
> -A
>
>
> On Fri, Nov 14, 2008 at 3:28 AM, nidhi mittal <[EMAIL PROTECTED]>wrote:
>
>>
>> actually i saw that ..
>> set_current_state (TASK_INTERRUPTIBLE)
>> schedule()
>>
>> as far as i understood
>> these two are independent statements
>>
>> where in first statement we just change the state variable in proces
>> descriptor
>> and in 2nd statement we put process to actual sleep
>>
>> now my ques is
>> if process is interrupted between these two statements by any means......
>> wont it be in some corrupt state
>> where its not sleeping but running but its state is changed to
>> TASK_INTERRUPTIBLE...............
>>
>>
>> pl clarify why didnt we make these statements as one atomic statement ....
>>
>>
>> --
>> Thanks & Regards
>> Nidhi
>>
>
>
>
> --
> http://linuxexplained.blogspot.com
>



-- 
Thanks & Regards
Nidhi

Reply via email to