Je remarque que si le nombre de threads ThreadPool max pour mon application IO-intensive est trop bas (16), alors mon interface graphique gèlera. Mais si je le place beaucoup plus haut (250), ça marche très bien.ThreadPool provoquant l'arrêt de l'interface graphique (?)
Quelqu'un peut-il expliquer ce phénomène?
Woah là! Ne jouez pas avec le compte ThreadPool à moins que vous ne sachiez ce que vous faites - beaucoup de services .NET essentiels peuvent l'utiliser, et en se basant sur le fait qu'il ne soit pas saturé. Vous avez presque certainement bloqué une partie du code IO de base à travers la saturation.
Je suppose que ce sont les ports d'achèvement IO qui vous trébuchement dans ce cas particulier ...
Joe Duffy (qui en sait plus sur le threading que je ne le fera jamais) a quelques réflexions sur ce here.
Comment le bloquer à travers la saturation - qui est simple à reproduire dans une expérience de pensée; Supposons que vous ayez un peu de code de travail qui doit faire 2 choses ... nous allons pousser 1 d'entre eux sur le ThreadPool, et en faire un nous-même; Après avoir fait notre propre travail, Join() [ou l'équivalent ThreadPool] la deuxième tâche afin que nous sachions que les deux ont fini. Maintenant, imaginons que nous commencions ce code de travail sur le dernier thread ThreadPool disponible: nous faisons notre propre travail, puis attendons un signal que la 2ème tâche est terminée - mais il n'y a pas de threads disponibles pour le faire! Et nous ne pouvons pas libérer les nôtres, car nous attendons toujours.
Vous pouvez faire la même chose avec les ports d'achèvement d'E/S.
Mais pourquoi cela préempter le thread graphique, qui n'est probablement pas alloué à partir du ThreadPool? – Chris
En outre, je n'utilise pas les ports d'achèvement d'E/S. – Chris
Le * système * pourrait les utiliser, bien que ... c'est ainsi qu'il parle (async) à différentes parties du système d'exploitation. –