Discussion :

[Faekk]

Bonjour.

J'ai créé une application qui lance actuellement une 20aine de threads.

Sous visualStudio tout fonctionne parfaitement.
Mais lorsque je lance l'application seule, tous les threads son bien créés, mais seuls 2 d'entre eux semblent être vivants (écriture dans un fichier log). Tous les autres semblent avoir gelé / disparu.

Donc ma question est: Quelles sont les valeurs par défaut que visual Studio affecte aux threads qui font que ça marche en dev, et pas en production ???

J'ai regardé le paramètre maxStackSize du constructeur. Si je met Int32.MaxValue, alors plus aucun thread n'est vivant, et si je met 1, alors je monte à 5 threads vivants (youpi).

Le fait de configurer mes threads en MultiAppartementThread ne change rien.

Quelqu'un a-t-il une idée à ce sujet ?

Merci par avance.

[DonQuiche]

Bonjour.

Par défaut il s'agit de 256ko. Cela dit, non seulement tu ne devrais pas chercher à t'en mêler à moins d'être sûr de ce que tu fais et, de toute façon, ton problème ne vient pas de là*, donc autant utiliser les constructeurs sans ce paramètre.

Ton problème vient plutôt de ce que font tes threads. Vérifie soigneusement l'onglet output de VS, n'hésite pas à configurer la gestion des exceptions (Debug > Exceptions), place des breakpoints ou des "trace" ingénieux, etc... Mais ton erreur est sans doute beaucoup plus bête que tu ne l'imagines et jamais je n'ai observé de bug dû à la taille de la pile même dans des applis avec de très nombreux threads. Enfin, MultiApartmentThread ne concerne que le développement COM.

* Le fait qu'en mettant des valeurs extrêmes tu vois le nombre de threads actifs changer ne signifie pas que ce soit la clé de ton problème : une taille de pile de 1 va donner une taille réelle de 65ko (arrondi au supérieur à la taille d'une page mémoire), une taille de pile maximale va entraîner un dépassement de capacité mémoire et une levée d'exception.

[Faekk]

Mon problème est que ça fonctionne tres bien en debug sous VS avec les paramètres par défaut, et que le comportement n'est plus du tout le même en execution sans VS.

J'ai trouvé une solution alternative en remplaçant mes threads par des timers, mais si quelqu'un sait pourquoi la gestion des threads est différente sous VS et hors VS, je suis preneur de la réponse.

[BenoitM]

La rapidité d'execution peut avoir des effets sur la gestion des threads

[Faekk]

Ces threads s'exécutent de façon cyclique en moins de 1s avant de se mettre en pause pour 5 à 10 secondes.

[Nathanael Marchand]

Pourquoi ne pas utiliser le threadpool?

[Faekk]

Effectivement, le threadpool pourrait bien être une solution.

Mais je ne comprend toujours pas ce que fait VS pour que mes threads fonctionnement parfaitement en debug et freezent en production...

[DonQuiche]

Dans tous les cas, j'insiste, l'erreur provient très vraisemblablement de ton code. Maintenant, concernant les différences entre debug hébergé dans VS et release, en voici quelques unes que je connais :
* En C++ l'hébergement en mode debug pose quelques chiens de garde pour éviter des problèmes tels qu'un buffer overflow qui peuvent se produire avec du code non-managé.
* En C++ la mémoire allouée est remplie avec des valeurs magiques en mode debug.
* En mode hébergé, le GC retarde le nettoyage de certaines variables locales et attend que la fonction qui les a déclarées soit complètement terminée.
* Bien évidemment, tous les appels à des fonction marquées avec un Conditional(Debug), comme toutes celles de la classe Debug par exemple, sont supprimés en mode release.
* Le code optimisé est... optimisé : beaucoup moins d'instructions "nop" (utilisées pour contenir les références au code source), certaines instructions supprimées (telles que les assignation de variables locales à null), etc.

Maintenant, le problème se produit-il aussi en mode release hébergé sous VS ? Ou seulement en mode debug hébergé sous VS ?

[Faekk]

Il n'y a PAS de problème en mode débug sous VS, et je n'ai pas de valeurs magiques puisque je développe en C#.

Par contre l'exécutable généré en debug a des problèmes si je l'exécute hors de VS.

Donc ce n'est pas un problème lié à l'optimisation du code...