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模式下运行，十次中有八次会出现死锁。如果我在 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.

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