CODEWITHSUNDEEP
multithreadinglinux-kernel
Kamiar
Kamiar

Reputation: 174

What is the necessity of calling set_current_state with TASK_RUNNING after the thread is woken up?

As far as I understood, after a Linux Kernel thread goes to interruptible sleep, it could be woken up by two things:

  1. by a wake_up family function call or
  2. by a signal.

I have seen the following pattern in the kernel. I am wondering what is the necessity of calling set_current_state(TASK_RUNNING) at line 8? Isn't it already in TASK_RUNNING state right now? 

1  set_current_state(TASK_INTERRUPTIBLE);
2  spin_lock(&list_lock);
3  if(list_empty(&list_head)) {
4         spin_unlock(&list_lock);
5         schedule();
6         spin_lock(&list_lock);
7  }
8  set_current_state(TASK_RUNNING);
9
10 /* Rest of the code ... */
11 spin_unlock(&list_lock);

Upvotes: 1

Views: 723

Answers (2)

feeling_lonely
feeling_lonely

Reputation: 6853

This is to avoid the lost wake-up problem. Read this.

Upvotes: 1

Andreas Bombe
Andreas Bombe

Reputation: 2470

If list_empty(&list_head) is false it will not call schedule() and go to sleep. In that case it needs to set its own state back to TASK_RUNNING to prevent inadvertent sleeps.

Upvotes: 3

Related Questions