Утечка памяти из критических разделов в Vista / Win2008?

Microsoft действительно изменила способ InitializeCriticalSection работы в Vista, Windows Server 2008 и, вероятно, также в Windows 7.
Они добавили «функцию» для сохранения некоторой памяти, используемой для отладочной информации, когда вы выделяете кучу CS. Чем больше вы выделяете, тем больше памяти сохраняется. Он может быть асимптотическим и в конечном итоге выровняться (не полностью купленный для этого).
Чтобы избежать этой «функции», вы должны использовать новый API InitalizeCriticalSectionEx и передать флаг CRITICAL_SECTION_NO_DEBUG_INFO.
Преимущество этого заключается в том, что это может быть быстрее, поскольку очень часто только spincount будет использоваться без фактического ожидания.
Недостатки в том, что ваши старые приложения могут быть несовместимы, вам нужно изменить свой код, и теперь он зависит от платформы (вы должны проверить версию, чтобы определить, какую из них использовать). А также вы теряете возможность отлаживать, если вам это нужно.

Тестовый комплект для зависания Windows Server 2008:
- создайте этот пример C ++ как CSTest.exe

#include "stdafx.h" 
#include "windows.h" 
#include <iostream> 

using namespace std; 

void TestCriticalSections() 
{ 
  const unsigned int CS_MAX = 5000000; 
  CRITICAL_SECTION* csArray = new CRITICAL_SECTION[CS_MAX];  

  for (unsigned int i = 0; i < CS_MAX; ++i)  
    InitializeCriticalSection(&csArray[i]);  

  for (unsigned int i = 0; i < CS_MAX; ++i)  
    EnterCriticalSection(&csArray[i]);  

  for (unsigned int i = 0; i < CS_MAX; ++i)  
    LeaveCriticalSection(&csArray[i]);  

  for (unsigned int i = 0; i < CS_MAX; ++i)  
    DeleteCriticalSection(&csArray[i]); 

  delete [] csArray; 
} 

int _tmain(int argc, _TCHAR* argv[]) 
{ 
  TestCriticalSections(); 

  cout << "just hanging around..."; 
  cin.get(); 

  return 0; 
}

-... Запустите этот командный файл (требуется sleep.exe из серверного SDK)

@rem you may adapt the sleep delay depending on speed and # of CPUs 
@rem sleep 2 on a duo-core 4GB. sleep 1 on a 4CPU 8GB. 

@for /L %%i in (1,1,300) do @echo %%i & @start /min CSTest.exe & @sleep 1 
@echo still alive? 
@pause 
@taskkill /im cstest.* /f

-... и вы увидите сервер Win2008 с 8 ГБ и четырехъядерным процессором, который зависнет до достижения 300 запущенных экземпляров.
-... повторите на сервере Windows 2003 и вы увидите, как он справляется с этим как с шармом.

Ваш тест, скорее всего, не отражает проблемы. Критические разделы считаются «облегченными мьютексами», потому что настоящий мьютекс ядра не создается при инициализации критического раздела. Это означает, что ваши 10 миллионов критических разделов - это просто структуры с несколькими простыми членами. Однако, когда два потока обращаются к CS одновременно, для их синхронизации действительно создается мьютекс - и это отдельная история.

Я предполагаю, что в вашем реальном приложении потоки сталкиваются, в отличие от вашего тестового приложения. Теперь, если вы действительно рассматриваете критические разделы как легкие мьютексы и создаете их много, ваше приложение может выделять большое количество реальных мьютексов ядра, которые намного тяжелее, чем объект легкого критического раздела. А поскольку мьютексы являются объектом ядра, их чрезмерное количество может серьезно повредить ОС.

Если это действительно так, вам следует уменьшить использование критических секций, где вы ожидаете много столкновений. Это не имеет ничего общего с версией для Windows, поэтому мое предположение может быть неверным, но все же это следует учитывать. Попробуйте отслеживать количество дескрипторов ОС и посмотрите, как работает ваше приложение.

Вы видите что-то еще.

Я только что собрал и запустил этот тестовый код. Каждый стат использования памяти постоянен - ​​частные байты, рабочий набор, фиксация и так далее.

int _tmain(int argc, _TCHAR* argv[])
{
    while (true)
    {
        CRITICAL_SECTION* cs = new CRITICAL_SECTION[1000000];
        for (int i = 0; i < 1000000; i++) InitializeCriticalSection(&cs[i]);
        for (int i = 0; i < 1000000; i++) DeleteCriticalSection(&cs[i]);
        delete [] cs;
    }

    return 0;
}