即使wake_up事件及时发生，wait_event_interruptible_timeout也会一直过期

Question

我对Android嵌入式平台（基于Exynos5dual）上的wait_event和wake_up的一些奇怪的行为有一个疑问，它带有先发制人的Linux 3.0内核。 在具有非抢占式内核（任何版本）的普通SMP笔记本电脑上发生不

我们有一个带有经典睡眠者/ waker场景的linux设备驱动程序，接下来会发生什么：

T0: taskA:
    if(!flag)
        wait_event_interruptible_timeout(wq, flag==true, timeout=0.5sec)

T1: (after a few msec) taskB: 
    atomic set flag
    wake_up_interruptible()

T2: (after timeout msec) taskA: 
    wait_event_interruptible_timeout expires (ret 0) instead of waking up at T1

对flag的所有读写都是原子的，并且已经从原子bitops（内核集/测试位），到volatile atomic_t，到使用atomic_t vars的每次读/写使用内存屏障（根据{{3}） }）

如果TaskA实际开始等待（wait_event_ *内核函数首先检查条件，所以情况可能并非总是如此），然后它等待完全超时，而不是在标志更改值和wake_up（）时被taskB唤醒被称为。

我们怀疑这两项任务发生在不同的核心上。 Core1在wait_event _ ..（）之后深度睡眠，并且无法通过在Core2上发生的wake_up_interruptible（）唤醒。

有人知道这是否属实，或者是否有其他责任？

注意：如果我们保存睡眠者的任务结构ptr然后在wake_up_interruptible之前（以及除此之外）执行 wake_up_process （saved_ptr），问题似乎就会消失（ ）。我们发现这不是最优的，并且想知道是否有更好的方法。