Is not changing the state to TASK_INTERRUPTIBLE before calling schedule() renders it not-schedulable? I thought task would be removed off run-queue by schedule() because it is in TASK_INTERRUPTIBLE state. I was making a sort of task queue. Threads puts themselves into this queue when a resource(say memory-space) is not available. And other thread, post releasing the memory space, will wake the first thread in queue. There are other means to achieve that, but I wondered why the above mentioned method did not succeed in making thread sleep. On Wed, Jun 11, 2014 at 11:21 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Wed, 11 Jun 2014 23:09:05 +0530, Joshi said:
set_current_state (TASK_INTERRUPTIBLE); schedule ();
Is this a sure-shot way of putting a thread to sleep, or are there conditions when this may not put the calling thread into sleep?
This will only succeed in guaranteeing the thread sleep if the thread has done something *else* to render it not schedulable. schedule() will return right back to that thread if it's the highest-priority thing that's runnable.
What problem are you trying to solve? Usually, you do that sort of schedule() when you're doing something that will take a relatively long chunk of time, and want other things to have a *chance* of running. But usually, you're perfectly happy with continuing to run if nobody else wants to run.
Why did you want a guaranteed sleep? If it's because you've started an I/O and you *know* it will be 125 milliseconds before you can make further progress, there's mdelay() and similar APIs... and so on for other reasons for wanting to sleep (for instance, blocking on a lock has an API, etc)
-- Joshi