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 <nidhimittal19@xxxxxxxxx> 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
