Version imprimable
Bonjour,
Je comptais utiliser les thread pour gérer un traitement lourd,et donc passer par Threadpool qui est très bien apparemment.
Et puis là j'ai eu un doute :
Vu que Threadpool est limité en nombre de thread, si j'utilise tous les threads pour mon traitement:
Un utilisateur lance le traitement: tous les thread du pool sont utilisé.
Un autre utilisateur lance le même traitement (et oui, c'est un site Web).
Que se passe-il?
Il me semble que le traitement est mis en attente, jusqu'à qu'un thread du pool se libère.
C'est une contrainte générique aux applications serveur, ce n'est pas spécifique au web.
C'est quoi la limite de threads?
Tu la positionnes via la méthode SetMaxThreads.
Je pige pas trop le problème? T'as peur d'atteindre le maximum de threads autorisés par le ThreadPool?
Dans la mesure où chaque requête client est traitée dans un thread à part, y aura autant de ThreadPools que de clients, donc pas de problème non?
Je pense en fait que le Threadpool est partagé non ?
Absolument pas; le ThreadPool est static. (heureusement d'ailleurs, sinon cette classe ne présenterait aucun intérêt :lol:).Citation:
Envoyé par lutecefalco
J'aimerai être sur de ça justement...Citation:
y aura autant de ThreadPools que de clients
J'y vois aucune raison mais peut-être que je me trompeCitation:
Envoyé par Pongten
Tout à fait (static pour être précis).Citation:
Envoyé par Pongten
Ok :mrgreen:Citation:
Envoyé par Bluedeep
Euh ... par définition on utilise le threadpool pour créer un cycle avec un nombre de thread ne dépassant pas la limite au sein d'une application. Si il n'était pas partagé, il ne présenterait absolument aucun intérêt.Citation:
Envoyé par lutecefalco
Donc si le Threadpool est statique, c'est bien ce que je craignais:
tous les utilisateurs se partagent le nombre de thread maximum du Threadpool.
C'est pas un peu limitant ça?
Oui, c'est son concept même.Citation:
Envoyé par gdkenny
Où est le problème ?
Si cela t'en pose un, peut être vient-il du fait que tu as choisi d'utiliser le ThreadPool pour un usage où ce choix n'est pas optimal.
Je ne l'ai pas encore utilisé, je préférai être sur avant :yaisse2:
J'ai besoin de faire un gros traitement multi-thread, sachant que le nombre de threads utilisés pour le traitement peut changer (selon l'input de l'utilisateur et le volume de données en base à cet instant)
L'interêt du pool, c'est que du boulot est déjà un peu pré-maché...
Mais si le nombre max de thread est limité, je ne peux pas l'utiliser du coup?
Si 35 utilisateurs lancent le traitement en même temps...
?
Pour ce genre de traitements, il faut créer et gérer soit même les threads?
C'est lourd ça :(
De toute façon, si tu prévois toi-même les threads et que tu en fixe un certain nombre par clients (par ex : 15), et que tu as 35 clients en même temps, ça va quand même te faire 525 threads, et je suis pas sur que niveau performance ce sera mieux que le temps d'attente dans le pool de threads...
Bon, ça fait encore un raison de ne pas passer par le pool dans mon cas.
Merci
A mon avis, tu as tout à gagner en passant par le ThreadPool. Si ce dernier a un nombre maximum de threads, c'est qu'il y a une bonne raison. A partir d'un certain nombre de threads, le processeur va perdre plus de temps à passer d'un thread à l'autre que de traiter le thread en cours. Je te conseille de lire les liens suivants :
http://msdn2.microsoft.com/en-us/lib...7y(VS.80).aspx
http://msdn2.microsoft.com/en-us/library/ms973903.aspx
http://en.csharp-online.net/Building...CLR_ThreadPool
Il y a un bon exemple si tu lances trois threads qui occupent le 100% du processeur, le threadpool va attendre que les deux premiers soient finis avant de lancer le troisième. Si tu gères toi-même tes threads, la performance sera moins bonne à mon avis...
L'inconvénient du threadpool, c'est que tu ne peux pas fixer de priorité à tes Threads. C'est la seule raison que je vois de gérer tes threads manuellement.
A toi de voir, mais je suis intéressé de savoir ce que tu en penses...
Salut,
en fait, la raison principale qui m'a fait ne pas choisir le threadpool,c'est le fait qu'il soit statique, et déconseillé dans le cas d'un traitement de premier plan.
J'ai l'impression qu'il est plus commun de l'utiliser dans le cadre d'une appli winform que webform.
De plus,dans mon cas,les traitements de synchronisation et de gestion des thread représentent une part infime du temps processeur.
le plus demandeur en temps CPU est le couple préparation de l'ordonnancement/traitement.
Voilà. Ceci dis,
:merci:
pour tes liens, je ne connaissais pas les 2 derniers.