感觉wait_event这里还是会有race condition

skyrim

1. #define __wait_event(wq, condition)                     \                       
   
2. do {                                    \                                       
   
3.     DEFINE_WAIT(__wait);                        \                              
   
4.                                     \                                          
   
5.     for (;;) {                          \                                       
   
6.         prepare_to_wait(&wq, &__wait, TASK_UNINTERRUPTIBLE);    \                                                                                                                                            
   
7.         if (condition)                      \                                   
   
8.             break;                      \                                       
   
9.         schedule();                     \                                       
   
10.     }                               \                                          
    
11.     finish_wait(&wq, &__wait);                  \                              
    
12. } while (0)

复制代码

上面是__wait_event代码，假如A进程准备进入for循环时，B进程使条件成立了，并且唤醒了一下这个wait queue，
但是A还没有加到wait queue上，因此A不知请，会继续执行prepqre_to_wait。
假设A刚执行完prepare_to_wait之后还没来得及再次检查condition就被抢占了，那A岂不是永远回不来了？
除非其他进程再次唤醒？

不知道我哪里理解的有问题，请各位大侠指点迷津！
谢谢！

怪怪虎

假设A刚执行完prepare_to_wait之后还没来得及再次检查condition就被抢占了，那A岂不是永远回不来了？

1. void fastcall
   
2. prepare_to_wait(wait_queue_head_t *q, wait_queue_t *wait, int state)
   
3. {
   
4.     unsigned long flags;
   
5.     wait->flags &= ~WQ_FLAG_EXCLUSIVE;
   
6.     spin_lock_irqsave(&q->lock, flags);
   
7.     if (list_empty(&wait->task_list))
   
8.         __add_wait_queue(q, wait);
   
9.     if (is_sync_wait(wait))
   
10.         set_current_state(state);
    
11.     spin_unlock_irqrestore(&q->lock, flags);
    
12. }

复制代码

把进程设置成了不可中断了。我觉得它会或者条件成立，或者被schedule()

skyrim

回复 2# 怪怪虎


    楼上意思是当进程状态为TASK_UNINTERRUPTABLE时，不会被抢占？

灌水菜鸟

回复 1# skyrim


    看看PREEMPT_ACTIVE是怎么用的。你说的这种情况下即便被抢占，它也不会因此被踢出运行队列的，也就是说还是会自动被调度回来的。

honkiko

回复 1# skyrim

刚执行完prepare_to_wait然后发生抢占，跟自己主动调schedule()效果是一样的啊。自己调schedule()怎么回来的，被抢占之后就是怎么回来的。
TASK_UNINTERRUPTIBLE状态下schedule()会被从rq里面remove掉，只能是被wake_up重新加入rq的。
   

honkiko

回复 4# 灌水菜鸟


current->state不为零(TASK_RUNNING)的情况下，schedule()中切换到其他进程之后，本进程应该会被踢出运行队列的(deactivate_task)。

skyrim

回复 4# 灌水菜鸟


    哦，有点印象了，记得以前看过Robert love讲这个PREEMPT_ACTIVE的作用的，再找找去

skyrim

找着了，分享下。
确实，当进程状态在TASK_INTERRUTPABLE等状态时如果被抢占不会被踢出调度队列。

On Thu, 2004-03-18 at 14:51, Julien.Soula@lifl.fr wrote:
> the PREEMPT_ACTIVE flag set by preempt_schedule() or during return of
> interrupt / exception / syscall. And it's tested in schedule() to
> avoid some operations like deactivate_task().
>
> Our purpose is to force deactivation of the task. So we planned to set
> task state to TASK_INTERRUPTIBLE value and then to call
> schedule(). However the PREEMPT_ACTIVE flag can prevent it.
>
> So what is the significance of the PREEMPT_ACTIVE flag and the test in
> schedule() ?
It lets a task be preempted when state != TASK_RUNNING. By preventing
the task from being deactivated, it can be rescheduled correctly.
Otherwise, a task that was, say, TASK_INTERRUPTIBLE could be preempted
before it put itself on a wait queue.
Marking the task that is preempted is a simple solution to the race.
If you want to force the deactivation of the task, there is really no
difference. Set it to TASK_INTERRUPTIBLE, do whatever you need to do,
and call schedule().
PREEMPT_ACTIVE is unrelated to what you want to do.
        Robert Love

怪怪虎

Set it to TASK_INTERRUPTIBLE, do whatever you need to do, and call schedule().
>>>貌似设置成TASK_INTERRUPTIBLE后，它 和 schedule()之间的code，不会被抢占。 真是这样吗？

灌水菜鸟

回复 8# skyrim


    个人建议：能用汉语尽量用汉语，用大家的母语进行交流是对大家的一种尊重。