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

[Joshi <joshiiitr@xxxxxxxxx>]

But if the state is anything other than TASK_RUNNING, schedule() is attempts to remove the task off run queue.  

Please see below (implementation of __schedule, called by schedule()) - 

         /*
          * Make sure that signal_pending_state()->signal_pending() below
          * can't be reordered with __set_current_state(TASK_INTERRUPTIBLE)
          * done by the caller to avoid the race with signal_wake_up().
          */
         smp_mb__before_spinlock();
         raw_spin_lock_irq(&rq->lock);
 
         switch_count = &prev->nivcsw;
         if (prev->state && !(preempt_count() & PREEMPT_ACTIVE)) {
                 if (unlikely(signal_pending_state(prev->state, prev))) {
                         prev->state = TASK_RUNNING;
                 } else {
                         deactivate_task(rq, prev, DEQUEUE_SLEEP);
                         prev->_on_rq_ = 0;

At line 2684 task is removed. So it will be suspended.  However,as per line 2681, there  seems to be a case when it may not put a task to sleep. But I am not sure when that can happen.  Also comment at line 2672 talks about preventing a race-condition in the caller. I did not understand that. In the code-snippet(in my first post) I did not do anything special in caller to avoid any race condition!

On Thu, Jun 12, 2014 at 12:15 AM, Jeff Haran <Jeff.Haran@xxxxxxxxxx> wrote:

 

 

From: kernelnewbies-bounces@xxxxxxxxxxxxxxxxx [mailto:kernelnewbies-bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Joshi
Sent: Wednesday, June 11, 2014 11:33 AM
To: Valdis.Kletnieks@xxxxxx
Cc: kernelnewbies@xxxxxxxxxxxxxxxxx
Subject: Re: Putting a thread to sleep using schedule() is foolproof?

 

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.

 

I think TASK_INTERRUPTIBLE has to do with whether or not a task can be “interrupted” by a signal, as in wait_event_interruptible().

 

Jeff Haran

 

--
Joshi

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies