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, <[email protected]> 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
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
