Windows 临界区公平性

本文介绍了Windows 临界区公平性的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我有一个关于使用 EnterCriticalSection 和 LeaveCriticalSection 方法的 Windows 临界区公平性的问题.MSDN 文档规定:无法保证线程获得临界区所有权的顺序，但是，系统对所有线程都是公平的."问题出在我写的一个应用程序中，它阻塞了一些从不进入临界区的线程，即使经过很长时间；所以我用一个简单的 c 程序进行了一些测试，以验证这种行为，但是当你有很多线程并且里面有一些等待时间时，我注意到奇怪的结果.这是测试程序的代码:

I've a question about the fairness of the critical sections on Windows, using EnterCriticalSection and LeaveCriticalSection methods. The MSDN documentation specifies: "There is no guarantee about the order in which threads will obtain ownership of the critical section, however, the system will be fair to all threads."The problem comes with an application I wrote, which blocks some threads that never enter critical section, even after a long time; so I perfomed some tests with a simple c program, to verify this behaviour, but I noticed strange results when you have many threads an some wait times inside.This is the code of the test program:

CRITICAL_SECTION CriticalSection;

DWORD WINAPI ThreadFunc(void* data) {
  int me;
  int i,c = 0;;
  me = *(int *) data;
  printf(" %d started\n",me);
  for (i=0; i < 10000; i++) {
     EnterCriticalSection(&CriticalSection);
     printf(" %d Trying to connect (%d)\n",me,c);
     if(i!=3 && i!=4 && i!=5)
         Sleep(500);
     else
         Sleep(10);
    LeaveCriticalSection(&CriticalSection);
     c++;
     Sleep(500);
  }
  return 0;
}

int main() {
  int i;
  int a[20];
  HANDLE thread[20];

  InitializeCriticalSection(&CriticalSection);
  for (i=0; i<20; i++) {
        a[i] = i;
        thread[i] = CreateThread(NULL, 0, ThreadFunc, (LPVOID) &a[i], 0, NULL);
  }
}

这样做的结果是一些线程被阻塞了很多个周期，而另一些则经常进入临界区.我还注意到如果你改变更快的睡眠(10 毫秒)，一切可能会恢复公平，但我没有发现睡眠时间和公平之间有任何联系.但是，这个测试示例比我的真实应用程序代码要好得多，后者要复杂得多，并且实际上显示了某些线程的饥饿.为了确保饥饿的线程还活着并正常工作，我做了一个测试(在我的应用程序中)，我在临界区进入 5 次后杀死线程:结果是，最后，每个线程都进入，所以我确保所有这些都活着并在互斥锁上被阻止.我是否必须假设 Windows 对线程真的不公平?你知道这个问题的解决方案吗?

The results of this is that some threads are blocked for many many cycles, and some others enter critical section very often. I also noticed if you change the faster Sleep (the 10 ms one), everything might returns to be fair, but I didn't find any link between sleep times and fairness.However, this test example works much better than my real application code, which is much more complicated, and shows actually starvation for some threads. To be sure that starved threads are alive and working, I made a test (in my application) in which I kill threads after entering 5 times in critical section: the result is that, at the end, every thread enters, so I'm sure all of them are alive and blocked on the mutex.Do I have to assume that Windows is really NOT fair with threads?Do you know any solution for this problem?

Linux 中使用 pthreads 的相同代码，按预期工作(没有线程饥饿).

The same code in linux with pthreads, works as expected (no thread starves).

我找到了一个有效的解决方案，强制公平，使用 CONDITION_VARIABLE.可以从这篇文章(链接)推断出来，所需的修改.

I found a working solution, forcing fairness, using a CONDITION_VARIABLE.It can be inferred from this post (link), with the required modifications.

almost

Windows 临界区公平性

问题描述

推荐答案