小心pthread_cond_signal和SetEvent之间的差异

小心pthread_cond_signal和SetEvent之间的差异

 

转载时请注明出处和作者联系方式：http://blog.csdn.net/absurd

作者联系方式：Li XianJing <xianjimli at hotmail dot com>

更新时间：2006-12-19

 

今天帮同事查一个多线程的BUG，其中一个线程挂在g_cond_wait上不动了。从代码来看，看出不出任何问题，g_cond_wait和g_cond_signal是严格配对的。折腾了两个小时后，从LOG信息中发现，g_cond_wait和g_cond_signal的顺序有点问题，一个线程先调g_cond_signal，另外一个线程才调g_cond_wait。

 

g_cond_signal是glib的封装，在Linux下，是用pthread_cond_signal模拟的，在Win32下，是用SetEvent模拟的。在Win32下，SetEvent和WaitForSingleObject在两个线程中的调用顺序没有关系，奇怪，难道在linux下两者的调用顺序有影响吗？

 

看了pthread的代码，果然如此：pthread_cond_signal发现没有其它线程等待，它直接返回了(见用红色高亮的代码)。

int pthread_cond_signal(pthread_cond_t *cond)

{

    if (cond == NULL)

        return pth_error(EINVAL, EINVAL);

    if (*cond == PTHREAD_COND_INITIALIZER)

        if (pthread_cond_init(cond, NULL) != OK)

            return errno;

    if (!pth_cond_notify((pth_cond_t *)(*cond), FALSE))

        return errno;

    return OK;

}

int pth_cond_notify(pth_cond_t *cond, int broadcast)

{      

    /* consistency checks */

    if (cond == NULL)

        return pth_error(FALSE, EINVAL);

    if (!(cond->cn_state & PTH_COND_INITIALIZED))

        return pth_error(FALSE, EDEADLK);

   

    /* do something only if there is at least one waiters (POSIX semantics) */

    if (cond->cn_waiters > 0) {

        /* signal the condition */

        cond->cn_state |= PTH_COND_SIGNALED;

        if (broadcast)

            cond->cn_state |= PTH_COND_BROADCAST;

        else

            cond->cn_state &= ~(PTH_COND_BROADCAST);

        cond->cn_state &= ~(PTH_COND_HANDLED);

   

        /* and give other threads a chance to awake */

        pth_yield(NULL);

    }

 

    /* return to caller */

    return TRUE;

}

 

晚上回家后，我又看了reactos关于SetEvent的实现。结果也意料之中：没有线程等待这个Event时，它仍然会设置SignalState(见用红色高亮的代码)。

LONG

STDCALL

KeSetEvent(PKEVENT Event,

           KPRIORITY Increment,

           BOOLEAN Wait)

{

    KIRQL OldIrql;

    LONG PreviousState;

    PKWAIT_BLOCK WaitBlock;

 

    DPRINT("KeSetEvent(Event %x, Wait %x)/n",Event,Wait);

 

    /* Lock the Dispathcer Database */

    OldIrql = KeAcquireDispatcherDatabaseLock();

 

    /* Save the Previous State */

    PreviousState = Event->Header.SignalState;

 

    /* Check if we have stuff in the Wait Queue */

    if (IsListEmpty(&Event->Header.WaitListHead)) {

 

        /* Set the Event to Signaled */

        DPRINT("Empty Wait Queue, Signal the Event/n");

        Event->Header.SignalState = 1;

    } else {

 

        /* Get the Wait Block */

        WaitBlock = CONTAINING_RECORD(Event->Header.WaitListHead.Flink,

                                      KWAIT_BLOCK,

                                      WaitListEntry);

 

 

        /* Check the type of event */

        if (Event->Header.Type == NotificationEvent || WaitBlock->WaitType == WaitAll) {

 

            if (PreviousState == 0) {

 

                /* We must do a full wait satisfaction */

                DPRINT("Notification Event or WaitAll, Wait on the Event and Signal/n");

                Event->Header.SignalState = 1;

                KiWaitTest(&Event->Header, Increment);

            }

 

        } else {

 

            /* We can satisfy wait simply by waking the thread, since our signal state is 0 now */

            DPRINT("WaitAny or Sync Event, just unwait the thread/n");

            KiAbortWaitThread(WaitBlock->Thread, WaitBlock->WaitKey, Increment);

        }

    }

 

    /* Check what wait state was requested */

    if (Wait == FALSE) {

 

        /* Wait not requested, release Dispatcher Database and return */

        KeReleaseDispatcherDatabaseLock(OldIrql);

 

    } else {

 

        /* Return Locked and with a Wait */

        KTHREAD *Thread = KeGetCurrentThread();

        Thread->WaitNext = TRUE;

        Thread->WaitIrql = OldIrql;

    }

 

    /* Return the previous State */

    DPRINT("Done: %d/n", PreviousState);

    return PreviousState;

}

 

 

而在KeWaitForSingleObject中，它发现SignalState大于0，就会Wait成功(见用红色高亮的代码)。

NTSTATUS

STDCALL

KeWaitForSingleObject(PVOID Object,

                      KWAIT_REASON WaitReason,

                      KPROCESSOR_MODE WaitMode,

                      BOOLEAN Alertable,

                      PLARGE_INTEGER Timeout)

{

         ...

if (CurrentObject->Header.SignalState > 0)

        {

            /* Another satisfied object */

            KiSatisfyNonMutantWait(CurrentObject, CurrentThread);

            WaitStatus = STATUS_WAIT_0;

            goto DontWait;

        }

...

}

 

由此可见，glib封装的g_cond_signal/g_cond_wait在Win32下和Linux下行为并不完全一致。即使不使用glib的封装，自己封装或者直接使用时，也要小心这个微妙的陷阱。

 

~~end~~