Dear Gaurav .... I'll try to help...actually I just read the related function couple hours ago..but I think I understand something... > returns true on on wait element. Now the question is what is this new > concept of sync wait and async wait and why we are not updating the > task state form TASK_RUNNING to TASK_UNINTERRUPTIBLE in all cases. As > we do not remove the current process from runqueue and also not > changing the state of current task from TASK_RUNNING to > TASK_UNINTERRUPTIBLE, wont this allow our current task to be > schedulable, which we dont want. I think the key here is by reading the definition of is_sync_wait #define is_sync_wait(wait) (!(wait) || ((wait)->task)) So, here I think "wait" is considered as synchronous wait if it is indeed related with a process (task). If this "wait" is indeed related with a process, then task-state if changed into uninterruptible sleep. This made the process kicked out from the runqueue when the schedule() is called. And will be woken up strictly when something wake it up (e.g wake_up() ) And, what is Async I/O? I think, since it is mentioned as "not related with any task", i only imagine it is a function that is executed strictly when certain condition met. And since it is not related with any task( i think in this case, the task is actually current task) , the task can be safely left out at TASK_RUNNING and scheduled out at the next step. Yes, the task might hit back quickly if it is the only process marked as TASK_RUNNING, but since the process itself got nothing to do with the event, it doesn't bring any disadvantage... regards Mulyadi -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
