Putting a thread to sleep using schedule() is foolproof?

[Joshi]

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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140612/3abe248b/attachment.html