2009-07-01 6 views
3

J'ai une application Windows C++ qui contient un std::hash_set contenant environ 5 millions d'entrées chacune avec 32 octets. Si je crée le hash_set dans un (plusieurs) threads séparé, il utilise> 1 Go selon ProcessExplorer. Je vois ça quand je libère la liste. Si je le crée dans le thread principal, il faut 200 MB. Ce phénomène ne s'applique qu'à la version 32 bits de mon application. Il n'écoute pas avec la version x64. J'utilise un dual core quad avec Win XP x64. Ce n'est pas une fuite de mémoire. Tout est libéré sur clear().Pourquoi plusieurs threads mangent-ils ma mémoire?

Ma conjecture: Windows 32.Bit n'est pas construit pour beaucoup de threads/beaucoup de cœurs.

Qu'est-ce que c'est?

+3

Il est tout à fait concevable que l'explorateur de processus soit erroné. –

+5

Chaque thread a une pile associée, mais cela ne peut pas tenir compte de toute cette mémoire à moins que vous ne lanciez plusieurs centaines de threads. Besoin de code pour faire une "réponse digne" deviner, mais Win32 fait vraiment bien multi-thread bien; Quelque chose d'autre se passe ici. –

+0

@neil: J'ai aussi vérifié cela avec vmmap. Je sais que tous ces péages ne sont pas exacts - mais ils n'ont pas totalement tort. Surtout: L'application 32Bit manque de mémoire plus rapidement lors de l'utilisation des discussions. @Kevin: J'utilise environ 20-30 threads aux heures de pointe. La plupart d'entre eux sont terminés avant d'appeler clear(). –

Répondre

6

La structure de données est finalement allouée à partir du tas, et c'est le même tas quel que soit le thread. Faire des appels de tas à partir d'un thread différent ne va pas affecter la quantité de mémoire allouée. Soit vos outils vous mentent, soit vous attribuez le hash_set sur plusieurs autres threads par accident.

Questions connexes