c++ - Win32 线程无缘无故地死掉

Question

我有一个程序生成 3 个工作线程，这些工作线程执行一些数字运算，并等待它们像这样完成:

#define THREAD_COUNT 3
volatile LONG waitCount;
HANDLE pSemaphore;

int main(int argc, char **argv)
{
    // ...

    HANDLE threads[THREAD_COUNT];
    pSemaphore = CreateSemaphore(NULL, THREAD_COUNT, THREAD_COUNT, NULL);
    waitCount = 0;

    for (int j=0; j<THREAD_COUNT; ++j)
    {
        threads[j] = CreateThread(NULL, 0, Iteration, p+j, 0, NULL);
    }
    WaitForMultipleObjects(THREAD_COUNT, threads, TRUE, INFINITE);

    // ...
}

工作线程在代码中的某些点使用自定义 Barrier 函数来等待所有其他线程到达 Barrier:

void Barrier(volatile LONG* counter, HANDLE semaphore, int thread_count = THREAD_COUNT)
{
    LONG wait_count = InterlockedIncrement(counter);
    if ( wait_count == thread_count )
    {
        *counter = 0;
        ReleaseSemaphore(semaphore, thread_count - 1, NULL);
    }
    else
    {
        WaitForSingleObject(semaphore, INFINITE);
    }
}

(基于this answer的实现)

程序偶尔会死锁。如果那时我使用 VS2008 来中断执行并在内部进行挖掘，则只有 1 个工作线程在 Barrier() 的 Wait... 行上等待。 waitCount 的值始终为 2。

让事情变得更尴尬的是，线程工作得越快，它们就越有可能死锁。如果我在 Release 模式下运行，10 次中大约有 8 次出现死锁。如果我在 Debug模式下运行并在线程函数中放置一些打印以查看它们挂起的位置，它们几乎不会挂起。

所以看起来我的一些工作线程被提前杀死了，剩下的就卡在了 Barrier 上。然而，线程除了读取和写入内存(并调用 Barrier())外几乎什么都不做，而且我非常肯定不会发生段错误。也有可能我得出了错误的结论，因为(如上面链接的问题中所述)我是 Win32 线程的新手。

这里可能发生了什么，我如何使用 VS 调试这种奇怪的行为？

Answer 1

How do I debug weird thread behaviour?

不完全是你说的那样，但答案几乎总是:真正理解代码，理解所有可能的结果并找出正在发生的结果。调试器在这里变得没那么有用了，因为你可以跟随一个线程而错过导致其他线程失败的原因，或者跟随父线程，在这种情况下执行不再是顺序的，你最终会到处都是。

现在，进入问题。

pSemaphore = CreateSemaphore(NULL, THREAD_COUNT, THREAD_COUNT, NULL);

来自MSDN documentation :

lInitialCount [in]: The initial count for the semaphore object. This value must be greater than or equal to zero and less than or equal to lMaximumCount. The state of a semaphore is signaled when its count is greater than zero and nonsignaled when it is zero. The count is decreased by one whenever a wait function releases a thread that was waiting for the semaphore. The count is increased by a specified amount by calling the ReleaseSemaphore function.

和here :

Before a thread attempts to perform the task, it uses the WaitForSingleObject function to determine whether the semaphore's current count permits it to do so. The wait function's time-out parameter is set to zero, so the function returns immediately if the semaphore is in the nonsignaled state. WaitForSingleObject decrements the semaphore's count by one.

所以我们在这里要说的是，信号量的计数参数告诉您一次允许多少线程执行给定任务。当您最初将计数设置为 THREAD_COUNT 时，您允许所有线程访问“资源”，在这种情况下，该资源将继续向前。

您链接的答案使用信号量的这种创建方法:

CreateSemaphore(0, 0, 1024, 0)

这基本上是说没有线程被允许使用该资源。在您的实现中，信号量被发出信号(>0)，因此一切都在愉快地进行，直到其中一个线程设法将计数减少到零，此时其他线程等待信号量再次发出信号，这可能是'不会与您的柜台同步发生。请记住，当 WaitForSingleObject 返回时，它会减少信号量上的计数器。

在您发布的示例中，设置:

::ReleaseSemaphore(sync.Semaphore, sync.ThreadsCount - 1, 0);

之所以有效，是因为每个 WaitForSingleObject 调用都会将信号量的值减 1，并且有 threadcount - 1 需要执行，这发生在 threadcount - 1 WaitForSingleObject 全部返回，所以信号量回到 0，因此再次取消信号，所以在下一次传递中每个人都在等待，因为没有人被允许立即访问资源。

简而言之，将您的初始值设置为零，看看是否能解决问题。

---

编辑 一点解释:换个角度想，信号量就像一个 n 原子门。你所做的通常是这样的:

// Set the number of tickets:
HANDLE Semaphore = CreateSemaphore(0, 20, 200, 0);

// Later on in a thread somewhere...
// Get a ticket in the queue
WaitForSingleObject(Semaphore, INFINITE); 

// Only 20 threads can access this area 
// at once. When one thread has entered 
// this area the available tickets decrease 
// by one. When there are 20 threads here
// all other threads must wait.

// do stuff

ReleaseSemaphore(Semaphore, 1, 0);
// gives back one ticket.

因此，我们将信号量放在这里的用途并不完全是它们设计的用途。