Sezioni critiche che perdono memoria su Vista/Win2008?

Question

Sembra che l'utilizzo di sezioni critiche piuttosto in Vista/Windows Server 2008 porti al sistema operativo che non riguadagna completamente la memoria. Abbiamo riscontrato questo problema con un'applicazione Delphi ed è chiaramente dovuto all'utilizzo dell'API CS. (Vedi questo SO question)

Qualcun altro ha visto con le applicazioni sviluppate con altri linguaggi (C++, ...)?

Il codice di esempio è stata appena initialzing 10000000 CS, quindi eliminarli. Funziona bene in XP/Win2003 ma non rilascia tutta la memoria di picco in Vista/Win2008 fino alla fine dell'applicazione.
Più si utilizza CS, più l'applicazione conserva memoria per niente.

Answer 1

Microsoft hanno infatti cambiato il modo InitializeCriticalSection opere su Vista, Windows Server 2008, e probabilmente anche Windows 7.
hanno aggiunto una "caratteristica" di mantenere una certa memoria utilizzata per le informazioni di debug quando si assegna un gruppo di CS. Più si assegna, più memoria viene mantenuta. Potrebbe essere asintotico e alla fine appiattirsi (non completamente acquistato per questo).
Per evitare questo "caratteristica", è necessario utilizzare la nuova API InitalizeCriticalSectionEx e passare il flag CRITICAL_SECTION_NO_DEBUG_INFO.
Il vantaggio è che potrebbe essere più veloce poiché, molto spesso, verrà utilizzato solo lo spincount senza dover attendere effettivamente.
Gli svantaggi sono che le vecchie applicazioni possono essere incompatibili, è necessario modificare il codice ed è ora dipendente dalla piattaforma (è necessario verificare la versione per determinare quale utilizzare). E inoltre si perde la possibilità di eseguire il debug se necessario.

kit di test per bloccare Windows Server 2008:
- costruire questo esempio C++ come 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; 
} 

-... eseguire questo file batch (ha bisogno del sonno.exe da SDK del server)

@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 

-... e vedere un server Win2008 con 8GB e quad core CPU di congelamento prima di raggiungere i 300 casi lanciati.
-... ripetere su un server Windows 2003 e vederlo gestirlo come un incantesimo.

Answer 2

Stai vedendo qualcos'altro.

Ho appena costruito & eseguito questo codice di prova. Ogni statistica di utilizzo della memoria è costante: byte privati, set di lavoro, commit e così via.

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; 
} 

Answer 3

Probabilmente il test non rappresenta il problema. Le sezioni critiche sono considerate "mutex leggeri" perché un vero mutex del kernel non viene creato quando si inizializza la sezione critica. Ciò significa che le sezioni critiche 10M sono solo strutture con pochi membri semplici. Tuttavia, quando due thread accedono a un CS allo stesso tempo, per sincronizzarli viene effettivamente creato un mutex - e questa è una storia diversa.

presumo nelle vostre discussioni reale app fanno collidere, in contrapposizione al vostro test app. Ora, se stai veramente trattando le sezioni critiche come mutex leggeri e ne crei molti, la tua app potrebbe allocare un gran numero di mutex del kernel reali, che sono molto più pesanti dell'oggetto light critical section. E poiché i mutex sono oggetti del kernel, la creazione di un numero eccessivo di essi può davvero danneggiare il sistema operativo.

Se questo è davvero il caso, si dovrebbe ridurre l'utilizzo di sezioni critiche in cui ci si aspetta un sacco di collisioni. Questo non ha nulla a che fare con la versione di Windows, quindi la mia ipotesi potrebbe essere sbagliata, ma è ancora qualcosa da considerare. Prova a monitorare il numero di handle del sistema operativo e osserva come sta andando la tua app.